fix: make review_reply wait for the next submit

[handlename]

Why this change is necessary

A review would sometimes stop dead the moment it should have continued. The human clicked Submit, the page went quiet, and nothing happened until they typed "I submitted" into the chat by hand — at which point the agent picked the round up instantly, as if it had been there all along.

Session transcripts say exactly where it went. The agent replied, called review_progress(idle), summarised the round to its user and ended its turn — and from that moment nothing was subscribed to the next submit. MCP is pull-only: a submit nobody is waiting for reaches no one.

Everything else was doing its job. The wait that followed a manual "I submitted" returned the round in two seconds, so the sidecar, the sequence counters and the notifier had never lost anything; and a wait that ran past two minutes came back to the agent as a task notification and the round continued, so the long stdio call — the part this repository had flagged as "documented but unverified" — is not the fragile piece either. Retiring the MCP server, which was on the table when this started, would have changed nothing.

Big picture

図のソース / Diagram source (mermaid)

sequenceDiagram
    autonumber
    participant H as Human (page)
    participant S as Server (session)
    participant A as Agent

    A->>S: review_start
    S-->>H: serve the review page
    A->>S: review_wait
    Note over S,A: the call blocks until a submit arrives
    H->>S: Submit (comments)
    S-->>A: review_wait returns the comments
    A->>A: edit the document
    A->>S: review_reply (inline replies)

    alt before: reply returns at once
        S-->>A: returns immediately
        A-->>H: summarise the round, then end the turn
        H->>S: Submit again
        Note over S,A: no waiter: the submit reaches no one
        H->>A: the human says "I submitted" by hand
    else after (this PR): reply also waits
        S->>S: record the replies, keep waiting
        H->>S: Submit again
        S-->>A: the same review_reply call returns the next round
        Note over S,A: the loop continues on its own
    end

Loading

Approach

review_reply now writes the replies and then waits for the next submit, returning what review_wait returns. Closing a round and entering the next wait are the same call, so the gap cannot open — the fix is structural rather than a matter of instructing the agent more firmly, which is what a pull-only protocol needs. review_wait stays for the first wait after review_start and for resuming after a timeout.

Alternatives considered and rejected: replacing MCP with another transport (the evidence clears MCP); a Stop hook that refuses to end the turn while a review is open (client-specific, and unnecessary once the tool surface closes the gap); strengthening the skill wording alone (leaves compliance to the model, which is the thing that failed).

One assumption is baked in: review_reply always waits, with no escape hatch, because mid-round reporting is what review_progress is for. If a case for replying without waiting shows up, a flag can be added later.

Design Documents

• DESIGN.md §E — MCP Server, updated in this PR with the contract and the reasoning above.

Review Points

• Is "a reply always waits" the right invariant, or should the escape hatch exist from the start?
• The waiting call must not hold the feedback sidecar lock, or the human's Submit would hang against the very call it is meant to release. A test pins this.
• The embedded skill now calls review_progress(idle) before review_reply, since the reply no longer returns until the next round.
• Verified beyond the unit tests: a live review over the real MCP surface, three rounds of human Submit and agent reply, with zero manual prompting, ending on session_ended from End Review.