bridge: answers to resynced asks fall through to a new run — resync parks the ask without a resolver

[bigduu]

Found while fixing #6 (see PR #8's "not fixed here" note).

resync_pending_asks (post-restart ask recovery) re-parks the pending question as state.pending_ask = Some(parked) but never sets state.ask_resolution — there is no waiting render_until_settled task after a restart, so there's no sender to park.

When the user then answers, try_resolve_pending_ask does:

let ask_ref = state.pending_ask.as_ref()?;
let answer = resolve(ask_ref)?;            // matches!
let sender = state.ask_resolution.take()?; // None → whole fn returns None

so the MATCHED answer is treated as a non-match: it falls through to the normal busy/queue routing and process_one starts a NEW run on a session that is still suspended on the pending question server-side. The user's answer is effectively dropped (and a rogue execution is queued), instead of resolving the question they can still see in their chat.

Sketch of a fix: in the ask fast-path, when pending_ask matches but ask_resolution is None (the resynced case), resolve inline — clear the ask, subscribe_session + POST /respond (subscribe-first, per PR #8), and spawn render_until_settled with the answering message's reply_ctx to watch the resumed run. The answering message itself carries the ReplyCtx that resync couldn't recover.

https://claude.ai/code/session_014iw5PBsSzDFHus1GfkAK4y