surface.wait and agent.prompt: server-owned waits on the socket

[arzafran]

An agent orchestrating a sibling today has to poll read_text in a loop and guess when the other side is done. Polling is racy (state can flip between two calls) and burns tokens doing nothing.

Design

Waits become server-owned and event-driven: the app watches state internally and answers the socket call when the condition is met, so there's no gap between "check" and "act".

• surface.wait: block (with timeout) until a surface hits a condition: agent idle, output matches a pattern, or process exit. One-shot, no subscription machinery needed by the caller.
• agent.prompt: submit a prompt to an agent surface and wait for it to finish, one request. The combined call is what makes "ask the sibling agent to do X, then continue" a single step instead of send + poll loop.

Pairs with #164: "agent idle / working / blocked" needs the status model from that issue. Pattern and exit waits don't, and can land first.

Tasks

1. surface.wait with pattern and exit conditions (verify: tests_v2 case where a wait resolves on a marker printed 2s later, and a parallel state change can't be missed)
2. surface.wait on agent state, once Agent status at a glance: blocked / working / idle badges on tabs, sidebar, and menu bar #164's model exists
3. agent.prompt built on 1+2
4. CLI verbs + socket docs; wire into the agent skill (Ship a programa agent skill: packaged instructions so agents can drive the app #165)

Off-main handling per the socket threading policy; these calls hold a connection open, so they must not block the command queue.