docs(finish_scan): elevate the active-agent check to a mandatory pre-flight

Audit flagged that legacy ``finish_scan`` had a code-level guard
(``_check_active_agents``) that refused completion if any subagent was
still running or stopping. Restoring it as code would be defensive
mid-stream cancellation we don't actually want — the agent should
choose whether to wait, message, or stop each child.

Lift the responsibility to the prompt instead: docstring now opens
with a numbered pre-flight checklist that requires the agent to
``view_agent_graph`` first and refuses self-permission to call
``finish_scan`` while any peer is in ``running`` / ``waiting`` /
``llm_failed``. The model sees this as part of the tool's schema and
treats it as a hard rule (matches our pattern for similar
constraints).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

strix/tools/finish/tool.py

@@ -86,14 +86,21 @@ async def finish_scan(
     2. Writes the four narrative sections to the scan record.
     3. Marks the scan completed and stops execution.
 
-    **Pre-flight checklist:**
+    **Pre-flight checklist (mandatory — do not skip):**
 
-    - All vulnerabilities you found are filed via
-      ``create_vulnerability_report`` (un-reported findings are not
-      tracked and not credited).
-    - All subagents have terminated. If any are still ``running`` /
-      ``stopping``, message them or use ``wait_for_message``.
-    - Don't double-report — one report per distinct vulnerability.
+    1. **Call ``view_agent_graph`` first.** Inspect every entry in the
+       summary. If ANY agent is in ``running`` / ``waiting`` /
+       ``llm_failed`` state, you MUST NOT call ``finish_scan`` yet —
+       wrap them up first via ``send_message_to_agent`` (ask them to
+       finish), ``wait_for_message`` (block until their report
+       arrives), or ``stop_agent`` (graceful cancel). Only ``completed``
+       / ``crashed`` / ``stopped`` agents are safe to leave behind.
+       Calling ``finish_scan`` while children are alive orphans their
+       work and produces an incomplete report.
+    2. All vulnerabilities you found are filed via
+       ``create_vulnerability_report`` (un-reported findings are not
+       tracked and not credited).
+    3. Don't double-report — one report per distinct vulnerability.
 
     **Calling this multiple times overwrites the previous report.**
     Make the single call comprehensive.