Async sub-agent payload names `wait_subagent`, a tool the caller does not have

What happens

The success payload for an async sub-agent dispatch tells the model it may "send more input, wait for completion, or perform a short timeout tick", pointing at a structured reference. On a live account run (core built from #6304 at 2abd462ec), the model followed that instruction and called wait_subagent — which is not on its belt. The call came back unknown tool, wasting a turn step.

Observed after a successful setup_skills hand-off.

Why it is the same class of bug as #6302

#6302 was, at root, prompt text naming tools the model could not call. This is the same failure one layer down: a tool result naming an action whose tool does not exist in the session. The model has no way to tell the difference between a capability it is being offered and one it is not.

Fix shape

Either name only what is actually on the caller's belt, or stop naming an action the payload cannot back. Whichever way, the text and the tool set should be derived from one source rather than written independently — the same correction #6304 applies to ## Connected MCP Servers and ## Installed Skills, which now name a hand-off only in the form the session can call.

Acceptance

The async-dispatch payload names no tool that is absent from the receiving session, pinned by a test that compares the names in the text against the session's callable set.

Found during the #6302 live acceptance run.