M5c-2 plan: task 08, recall's Honcho part; the wiring split out as task 09

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

docs/plans/M5c2/01-wire-ask-memory.md

@@ -12,7 +12,7 @@ agents, a question about one or two of its workspaces (M5c spec, section 9). Thi
 the tool's arguments to `bxcore`, with their shape checks, the way `recall`'s are there
 (`RecallArgs`, its name constant `RECALL`, its limit `MAX_QUERY`, and `RecallArgs::check`). Later
 tasks use them: task 02 (`brokerd` parses the arguments with them), task 04 (`loopd` declares the
-tool), tasks 09 and 10 (`memoryd` answers it).
+tool), tasks 10 and 11 (`memoryd` answers it).
 
 ```json
 {"question":"Who wrote the launch note?","workspaces":["fleet","boxmaker1"]}
@@ -24,7 +24,7 @@ tool), tasks 09 and 10 (`memoryd` answers it).
 - **`workspaces`**: optional; at most two names, none empty, none repeated, each 1 to 512
   characters of ASCII letters, digits, `_` and `-`. Missing, or `[]`, means the one workspace
   `own`, the agent's own trusted one. Whether a name is one this agent's `[honcho]` configuration
-  has is **not** checked here: `memoryd` checks that in task 09.
+  has is **not** checked here: `memoryd` checks that in task 10.
 - There is no other field, and an unknown field is refused, as in every argument type we define.
   (An earlier draft of the spec had a `reasoning` field; it was removed, and a given test sends
   it and expects a refusal.)