v0.5.0 — the panel comes first

Blocking is opt-in now, and off by default

0.4.0 held every opening call open until you decided. That logic works, and I measured it: a plain MCP client gets an answer from editor_pending in 4ms while propose_write is still open, and the whole accept/comment/discard round-trip completes in 138ms.

What it needs is the host to keep dispatching the panel's own calls during the call that created the panel. The MCP Apps spec requires no such thing:

The Host MAY forward any message from the View … it MAY decide to block some messages or subject them to further user approval.

At least one host doesn't forward them in time, so the panel never claims its proposal and sits on "Opening…" — a much worse trade than a review that doesn't block. --block-on-review turns the gate back on where the host allows it.

Why not elicitation? MCP's own primitive for pausing to ask is server.elicitInput, and its result is exactly accept | decline | cancel — a perfect fit on paper. It renders the client's form from a JSON schema, so adopting it would mean giving up the editor, which is the entire product. The Apps spec and the elicitation spec don't mention each other.

Added

• Fullscreen. The panel declares availableDisplayModes and asks via ui/request-display-mode, believing the host's answer rather than its own request. Hidden where the host never offered the mode.
• Send always delivers — resolves a waiting call when there is one, posts the comments as a message when there isn't.

187 tests. Reinstall the .mcpb below.