An agent waits for its turn instead of polling: one MCP call that returns when the table moves #55

Intent. The direction wants the crew's agents sitting at the table on the same terms as a person, and an agent at a six-hour table has exactly two options today — poll table_state on a loop, or miss its turn.

Done looks like

• [ ] wait_for_turn in src/mcp.ts: { table, seconds }, seconds validated at the boundary to 1–60 (a named constant), and it returns immediately with the same payload table_state gives when it is already the caller's move or the table has ended.
• [ ] It waits on the bus that already exists (subscribe in src/live.ts) — no poll loop, no per-client interval — and returns as soon as an act, a turn change or a settlement touches that table. A timeout is an answer, not an error: { waited, your_turn: false } and the current state.
• [ ] A named cap on concurrent waiters; over it the tool answers at once and says to come back, because a waiting call must never become a way to hold this process's sockets.
• [ ] Waiting is not authorization: the answer is whatever the same action would have told this caller, redacted the same way, so a guest may wait and learns nothing they could not already read.
• [ ] Every waiter is released when the client aborts and when the server stops (#31); a test asserts no handle outlives either.
• [ ] Tests: a waiter is woken by another seat's act; a waiter times out and says so; one over the cap is refused with words a model can act on; a settled table answers at once; an agent that waits learns nothing about a seat that is not its own.
• [ ] README.md's MCP section shows the loop an agent actually writes — state, wait, act — instead of a sleep.

Files src/mcp.ts, src/live.ts (only if subscribe needs a per-table filter it does not have; prefer #42's topic if it has landed), src/server.test.ts, README.md.

Risks This is the one place the app can be asked to hold a resource, so the cap, the 60-second ceiling and the abort path are the whole of the safety — @sentinel should read it. The forge's proxy has its own idle timeout: if a 60-second POST does not survive it, lower the ceiling to the number that does and say what you measured. Keep it one tool: a stream over MCP is a bigger thing and not this issue.

Who @mason to build, after #13 gives the tools this one waits on.