drop agent_forward from the shim (1135 bytes, 0 active forwards) and surface an active forward on register instead

Drop the agent_forward TOOL from the MCP shim. The HUB ROUTE STAYS - this removes the per-agent tool, not the capability. MEASURED 2026-09-11. Tool surface is 33 tools / 21,367 bytes / ~5,342 tokens injected into every agent window on every turn. agent_forward is 1,135 bytes, 5.3% of that, and the highest size-to-use ratio on the board: agent_forwards holds ZERO active rows of six ever created. Agents do not set forwards - only the target mailbox or Elazar may - so the tool's only self-service use is action=status, inspecting a forward nobody currently has. THE ONE REAL LOSS, AND IT MUST BE REPLACED RATHER THAN ACCEPTED. With the tool gone, an agent whose mail IS being forwarded has no way to discover that. An agent silently forwarded and an agent not forwarded become indistinguishable from inside the session - which is the exact negative-result-equals-failure-result class this stack keeps producing, and it would be introduced deliberately rather than by accident. Do not ship the deletion on its own. REPLACEMENT, and it is cheaper than the tool it removes: surface the forward on a path the agent ALREADY calls, and only when there is something to say. Add an active-forward field to the register response (and/or online) that is present ONLY when a forward is active, naming the destination. Absent field = no forward. That costs a few bytes in one response instead of 1,135 bytes in every window on every turn, and it reaches the agent at the moment it matters - session start - rather than requiring it to think to ask. WATCH-OUTS: - Elazar's override path must be unaffected. He sets forwards through the hub, not the shim; confirm no code path in the hub calls the shim tool. - Do not remove the hub route, the agent_forwards table, or agent_forward_events. The feature is dormant, not retired - it was used for four real CC-to-CA continuity forwards on 2026-08-28. - The new field must be ABSENT when there is no forward, not present-and-empty or present-and-false. A false-y present field is how this becomes a thing readers stop checking. - State in the register response comment that absence means no forward, so the next reader does not treat a missing field as 'not implemented'. WHY 2 AND 3 WERE DECLINED, recorded so nobody rebuilds them from the same measurement: folding the low-frequency blackboard verbs (4,352 bytes over 5 verbs) and eq verbs (1,307 over 5) into action-dispatchers was measured and rejected on proportion. A dispatcher does not save the byte sum - it still documents every action's parameters in its own schema, so the saving is the per-tool envelope, not the bodies - and it trades a surface every agent calls correctly today for one whose failure mode is a wrong action string. One malformed call costs a turn, ~150k of standing context, against a total trim worth under 1% of a turn. Revisit only if the context lever ever becomes smaller than this, which it is not close to being. Also relevant to ordering: blackboard is the LARGEST family at 35.6% of the surface and MSG-391 is about to halve the turns a board costs. Trimming the feature being made worth using would have been the wrong order. THE CAVEAT THAT BOUNDS ANY FUTURE TRIM ON THIS MEASUREMENT: the hub records NO per-tool call counts - no audit, route or metric table exists. Every usage figure above is inferred from SIDE EFFECTS, so it sees WRITE verbs only. read_unread, has_unread, roster, locks, aro_list, blackboard_read, eq_ls, version and online leave no trace whatsoever, and read_unread is near-certainly the most-called tool in the fleet. TRACE-ABSENCE IS NOT USE-ABSENCE. Any trim ranked by trace presence cuts the read path first, which is where the traffic actually is. Do not use the 30-day table as a call-count ranking. Lane: author the diff with proof, hand to pm-llmmsgsrv-cc to gate and deploy. Never applied by the coder. Queue BEHIND MSG-391, which is an Elazar implement-now.