Make fork reachable by the model in the acp-agent demo (review feedback)

The acp-agent cordis configs loaded the fork backend but bound only one
dsh-tool-subagent (to spawn), so the comment's claim that a multi-child scenario
could exercise both transports was false — fork was loaded but unreachable by
the model. Register a second dsh-tool-subagent bound to fork with a distinct
toolName (subagent_fork), matching the coding-agent demo, in both cordis.yml
(record/demo) and cordis.snapshot.yml (replay). Snapshot goldens are unchanged
(the transcript does not capture the available-tool list).

examples/acp-agent/cordis.snapshot.yml

@@ -42,8 +42,10 @@
       a fresh child agent (it works in its own context and returns only its
       final result) — give it a complete, standalone instruction.
 
-# The subagent seam + both in-process backends + the model-facing `subagent`
-# tool — identical to cordis.yml's wiring (only the LLM backend differs above).
+# The subagent seam + both in-process backends + two model-facing tools —
+# identical to cordis.yml's wiring (only the LLM backend differs above): spawn
+# and fork are each reachable via a dsh-tool-subagent bound to it with a distinct
+# toolName (subagent → spawn, subagent_fork → fork).
 - id: subagent
   name: '@deepseek-ai/dsh-subagent'
 
@@ -61,3 +63,10 @@
   name: '@deepseek-ai/dsh-tool-subagent'
   config:
     provider: spawn
+    toolName: subagent
+
+- id: tool-subagent-fork
+  name: '@deepseek-ai/dsh-tool-subagent'
+  config:
+    provider: fork
+    toolName: subagent_fork