2.1.x: `bloodhound` tool adapter (P3)

[AkhilSharma90]

What

Add a tool adapter that wraps bloodhound (AD attack-path enumeration (bloodhound + SharpHound)).

Tracked in IMPLEMENTATION_PLAN.md — see the unchecked checkbox in Phase 2.1. Priority P3. Related: 5.15.8 Network Services.

Why

Tool adapters are the swarm's atoms — each one extends what an agent can do during a campaign. Adding one is the cleanest possible scoped contribution: a new file in internal/tools/, a test file alongside it, a registration in the coordinator, and a plan check-off.

Acceptance criteria

• internal/tools/bloodhound.go implements the Tool interface (Name, IsAvailable, Run) following the shape of internal/tools/dalfox.go — the most recent reference adapter (see PR Model requirements #1, commit 802b97c).
• Scope is enforced before the subprocess is spawned (scope.ValidateAndLog).
• Output is parsed into ParsedFindings where the tool emits structured output (JSON, JSONL, XML). Raw output is always preserved.
• internal/tools/bloodhound_test.go covers at least the happy path (mocked subprocess or recorded fixture).
• The adapter is registered in the coordinator (internal/tools/coordinator.go) so it's discoverable by agents.
• The checkbox in IMPLEMENTATION_PLAN.md is ticked and the bullet rewritten to describe what shipped (paths, flags, behavior). See CONTRIBUTING.md §3.
• If the tool is not on most researcher laptops, add an install hint to the Dockerfile or to README "Optional tools".

Out of scope

• Wiring the adapter into a specific agent's prompt — that lives in a separate area-prompts task.
• Adding new specialization classes for findings the adapter produces — file as a follow-up.

Reference

• Pattern file: internal/tools/dalfox.go (~135 LOC)
• Test pattern: internal/tools/dalfox_test.go
• Coordinator: internal/tools/coordinator.go
• One-command invariant (CONTRIBUTING.md §1) — your adapter must not require new user configuration to work.

Comment to claim. A maintainer will assign you — typically same-day.