session-start: register MCP servers from the dispatcher when the setup script did not

[bdelanghe]

What was wrong

A session asked "what should we work on next?", found no next tool, and ranked the
org's work by hand from list_issues / list_pull_requests — the one move
front-desk-scheduler's CLAUDE.md forbids in its opening paragraph. Nothing in the
session said the tool was absent, so the answer was indistinguishable from Front Desk's.

~/.claude.json read mcpServers: null. The environment setup script had been reduced
to just the settings.json heredoc — 264 bytes, per Running initialization script in
the environment log — so its register-mcp.mjs call was simply gone.

Nothing was broken that anyone could see. The dispatcher ran, every repo's hook ran,
deno / dolt / node_modules were all present, and the MCP server started cleanly
when invoked by hand. One line was missing from a field no reviewer and no gate can
read — the infra#122 failure mode, one layer up from where this directory usually
argues about it.

What changed

The dispatcher now calls register-mcp.mjs itself before fanning out, and puts anything
still missing into the session context.

This works because the claim this repo carried — that registering after launch cannot
help, since servers resolve at launch — was only half right, and the wrong half was
load-bearing. Verified live on Claude Code 2.1.42: a session that started with
mcpServers: null gained the server's five tools within the same session, seconds
after the write, with no relaunch. The config is watched. Launch-time resolution is real
and still the ordering you want; it is not the only door.

It stays a fallback, not a relocation. The setup script is still the right primary
call site — it is ordered before anything reads the tool list — and a field that has
stopped calling register-mcp.mjs has probably stopped doing the rest of its job, so
stepping in is logged as a bug report against that field, not as a healthy session.

Files

• register-mcp.mjs — extract register() from main so it is callable
  in-process; add registrationStatus(), the read-only report. unregistered() is now
  the single definition of "not registered", shared by the writer and the report, so a
  drift check cannot come to disagree with what the writer would do.
• session-start-dispatch.mjs — register, then report. A missing
  register-mcp.mjs (the bootstrap verifies each fetched file independently, so a
  refused digest can leave one present and the other not) degrades to the previous
  behaviour and logs "could not check" — a different claim from "nothing is missing".
• README.md — record the 2026-08-01 recurrence, correct the launch-time claim, and
  fix two log-line examples that no longer match the code.

The warning block is deliberately repo-agnostic (which CLI substitutes for which server
is the declaring repo's knowledge) and is emitted only when registration did not
take — the healthy and self-healed paths cost zero context, since the org context file's
own header notes it is charged every session.

Verification

• 79 tests pass across the four .claude suites, including the bootstrap-pin gate.
• 11 new tests, plus end-to-end runs of the dispatcher against a scratch session root:
  nothing registered → self-heals and warns on stderr; re-run → no-op; unreadable
  ~/.claude.json → refused, file untouched, warning reaches session context; and
  register-mcp.mjs absent → degrades cleanly.
• The pin is untouched: FRESHNESS is not asserted on a PR, and org-defaults.yml
  opens the bump automatically once a merge commit exists.

Still needs a human

The setup-script field itself lives outside version control and I cannot edit it. It
should be returned to the canonical text in .claude/README.md — the missing call is:

if [ -f "$BOOT/register-mcp.mjs" ]; then
  CLAUDE_SESSION_ROOT="$ROOT" node "$BOOT/register-mcp.mjs" || true
fi

This PR means a session survives without it; it does not make it unnecessary.

---

Generated by Claude Code