fix(kimi): the launcher registers managed sessions; the hook adopts instead of minting (#40)

[XertroV]

Summary

Fixes #40: managed c2c start kimi -n <name> sessions never registered on the broker, so c2c send <name> failed outright with alias '<name>' is not registered.

Root cause — both of the issue's hypotheses were wrong

The hook does fire and does register. It registers the wrong identity.

Kimi Code ≥0.27 is a client/server split: sessions live in a shared, long-lived kimi server daemon, and that daemon spawns hook processes inheriting its environment. The managed identity vars c2c start sets on the TUI are therefore invisible to c2c hook kimi, which falls through to auto-minting a competing alias. This is structural, not a race — one daemon serves many sessions, so its env cannot identify any of them. The hook can never be the identity authority for a managed session; the launcher is the only component that knows -n.

Evidence: three managed starts produced three hook registrations and zero managed aliases.

Changes

• The launcher registers, before forking the client: session_id = <name>, alias = -n (or --alias/role override), recording launch cwd + outer pid, then reading the registry back to confirm. Failure is loud and actionable (and also written to broker.log — a message the full-screen TUI paints over isn't loud).
• The hook adopts a live managed row owning its cwd instead of minting a competitor; it declines with an explanation when two live managed instances share a directory.
• -n is the alias; divergence from --alias/role is stated explicitly.
• The previously-silent exit 0 on unresolvable session id now logs one stderr line (still exit 0).

Review round (PASS-WITH-NITS; all folded in)

The reviewer caught an interaction bug between this fix and #9: post-fix the managed case is alias == name == session_id, but decide_notifier_rekey treated requested_sid == alias as a placeholder and refused to re-key — silently disabling #9's convergence guard for exactly the configuration this issue targets (symptom: send succeeds, session deaf, after a SIGKILLed outer loop). Fixed with an explicit ?authoritative flag, claimed only when the launcher's own registration landed and the resolver picked that row — so a session_index sid or bare-alias fallback stays non-authoritative and #9's guarantee is untouched. Proven red by neutering the flag.

Also: registration moved before the fork (F3); pid_start_time corroboration on adoption (F4); failures mirrored to broker.log (F5); cwd realpath-normalized (F7). The reviewer's suggested "first-wins sid claim" for the co-located-vanilla case was deliberately declined — it would fix a cosmetic wrong-identity but could strand a managed session that re-mints its session id, trading cosmetic for real deafness on an unknown.

Verification — proven in the wild

Unit: test_c2c_hook_kimi 12, test_c2c_kimi_notifier 52, test_c2c_setup_kimi 22, test_c2c_doctor_hooks 46, test_c2c_start 207 — all green, built-first, fork-free. Red/green confirmed (3 of 4 new hook tests fail with the fix reverted).

Live tmux e2e (managed launch, kimi-code/k3):

• Registry row session_id=i40test, alias=i40test, launcher-registered — exactly one row.
• c2c send i40test → ok (pre-fix: not registered), delivery confirmed via REST state (last_prompt carries the envelope, busy: true) — 3.9s cold, 2.19s / 2.23s warm.
• Hook log: adopting managed session 'i40test' … — not minting a new alias.
• Notifier bound to i40test.inbox.json, drained to [].

Known follow-ups (filed separately, not blockers)

Teardown strips pid/pid_start_time from the managed row, making it unadoptable — so #40 can resurface after an unclean exit. The in-session MCP server registers a competing row because ~/.kimi-code/mcp.json pins one global install-time alias. c2c restart on kimi fails on a 5s outer-exit timeout (pre-existing; the diff touches no pidfile/timeout code).

Closes #40.