feat(mcp): deferred tool loading for the remaining subagent roles (self-review, scouts, goal assessor, review team, merge flow)

[OGtwelve]

Problem

#119 mounted the deferred MCP surface on the Worker and Reviewer; #193 added the CI-fix Worker and the Planner. Five roles still resolve their fixed slots only, so any surplus tool a domain server exports is dropped for them:

Role	Site
self-review Worker	run-loop-adapter.ts, the runSelfReviewSession wiring (resolveWorkerTools with no mountDeferredTools)
scout survey lead + scouts	planner-wiring.ts, surveyRepoForPlanner
goal assessor	planner-wiring.ts, defaultAssessGoal
review team lead + investigators	review-team-wiring.ts, investigateReviewThreads
merge / take-over Worker	merge-flow-adapter.ts

self-review postdates #193's text, which is why it was not named there.

What

Decide each role on its merits rather than mounting all five reflexively — #193 left them out deliberately, not by oversight:

• self-review is the closest call: it reviews a real diff adversarially and could plausibly want the domain server. Likely a yes.
• scouts survey local repo layout; their whole prompt is about structure, and a name-only index plus tool_search is prompt weight for a question they do not ask.
• goal assessor returns a short verdict; the same argument, more so.
• review team / merge flow — no strong case either way yet; measure before mounting.

The machinery is already in place and composes in three steps (extraTools, appendIndexBlock, withActiveTools), so each inclusion is small. withActiveTools already accepts an absent base step (#193), which is what these roles need.

Constraints (per CLAUDE.md)

Portable ESM, strict TS, paired *.test.ts; aitm is an MCP client only.

Acceptance criteria

• Each of the five roles is either mounted, with a test proving name-only + working tool_search activation, or has a one-line reason recorded in the code for staying out.
• Byte-identical behavior for every role when nothing is deferred.
• bun test + node --test + biome + tsc green in both packages.

Follow-up to #193, which closed the #119 follow-up for the two roles it named. Part of #196.

[OGtwelve]

Also in scope here: extract the deferred-mount composition

#193 made this the third and fourth copy of the same sequence, and CodeRabbit flagged it there (#334 review). It was deferred to this issue on purpose: the seam should be shaped by the roles it serves, and this is the issue that adds them.

Two distinct repetitions:

1. resolve surface → mountDeferredTools → merge extraTools → applyHooks — now in the Reviewer, Worker and CI-fix blocks of defaultMakeOrchestrator, plus defaultPlanGroups. A role-scoped helper returning { tools, mount } would collapse all four, but the resolvers differ in arity and shape (resolveWorkerTools takes eight arguments, resolvePlannerTools four, resolveReviewerTools a github tool mid-list), so the helper's signature should be read off the call sites rather than guessed.

2. mount && mount.activated !== null ? withActiveTools(base, tools, …) : base — in the same four places. Note a single signature does not cover them today: Worker and Reviewer always have a compaction base and assign into a required prepareStep, while CI-fix and the Planner may have no base at all (which is why withActiveTools took an optional one in feat(mcp): extend deferred tool loading to the CI-fix session (and evaluate Planner) #193). Either overloads, or a generic whose return follows the base.

Whoever does the five roles above should land the extraction in the same PR — at that point there are up to nine call sites and the right shape is legible.

[OGtwelve]

Scope grew: #192 found that the sharing is structural

#192 landed on-touch delivery for the Worker Coordinator, Reviewer, CI-fix and Planner, and scoped the Worker's editor leaves per agent (WorkerInput.nested + re-decoration in editor-fanout.ts). Two roles were deliberately left on hooks-only, and the reason is now concrete rather than a preference:

The announcement state lives with the decorated tool record, and these two teams share one across every member.

• surveyRepoForPlanner (planner-wiring.ts) builds one record into base, then spreads it into the scout-lead init AND every scout init.
• investigateReviewThreads (review-team-wiring.ts) builds readTools once for the lead and every investigator.

Both run their members concurrently, so an on-touch announcement would land on whichever member won the race — nondeterministically. Decorating them as-is would be worse than not decorating them.

The fix is the same one this issue is already about: the runner has to build its own record per agent. createScoutRunner/createReviewInvestigatorRunner already create a fresh agent per assignment (createSubagent inside the returned closure) — it is only init.tools that is shared, so the seam is a tools factory on ScoutAgentInit rather than a fixed record. That change serves the deferred-MCP mount (this issue's original subject) and the nested-config announcement equally, which is why they belong in one PR.

Also still open from the #193 review, unchanged: extracting the repeated resolve surface → mountDeferredTools → merge extraTools → applyHooks sequence and the withActiveTools ternary, once the roles above make the right shape legible.