fix(bridge): register resolver for resynced asks so answers resume the parked run

[bigduu]

Closes #9.

Root cause

resync_pending_asks (post-restart ask recovery) re-parks a pending question as state.pending_ask = Some(parked) but never sets state.ask_resolution — there's no waiting render_until_settled task after a restart to own that sender. When the user then answers, try_resolve_pending_ask matched the ask but required ask_resolution to also be Some, so the matched answer fell through to the normal busy/queue routing and process_one started a brand-new run on a session that was still suspended server-side waiting for that exact answer.

Fix

try_resolve_pending_ask now returns a PendingAskMatch enum distinguishing:

• Live(sender, answer) — the ordinary case, a render_until_settled task is waiting; unchanged behavior.
• Resynced(ParkedAsk, answer) — no live task (resync case). The caller resolves inline via a new resolve_resynced_ask, which reuses the exact subscribe-before-respond logic render_until_settled's live pause branch already used (extracted into respond_and_resubscribe), then keeps watching the resumed run through render_until_settled — using the answering message's own ReplyCtx, since resync itself never recovers one (documented on resync_pending_asks).

There's no ask_ref to edit in the resync case (resync never re-renders the ask as a message, per its existing doc comment), so the ✅-edit step from #8 is skipped there but stays unchanged on the live path.

busy is now set to true atomically, in the same lock as the match, when a resync answer is resolved — mirroring handle_inbound's own busy-then-spawn dance for a fresh message — so a message racing in immediately behind the answer queues instead of racing a second concurrent run onto the same session. drain_chat's queue-draining tail is extracted into drain_queue and reused by resolve_resynced_ask so busy is correctly cleared (and anything that queued up gets processed) once the resumed run settles.

Both handle_inbound (text answers) and handle_callback (button presses) were updated to handle the new PendingAskMatch variants.

Expired-ask semantics

No new "this ask expired" messaging was added. The bug was the silent fallthrough itself — once a resync-matched answer resolves inline instead of falling through, there's no more silent "start a new run" path left to guard against. Every remaining failure mode already has an explicit reply:

• respond/subscribe failures on the resync path → the existing "Failed to record your answer" / "Answer recorded, but failed to resume watching the run" replies (shared with the live path via respond_and_resubscribe).
• A stale pre-restart button nonce (resync always mints a fresh nonce, so an old visible button can never match post-restart) → the existing callback-path "This action has expired." ack, unchanged and still exercised in the resync scenario (see the new resync_pre_restart_button_nonce_is_stale_and_reports_expired test).
• Ordinary non-matching text that isn't an answer at all → still falls through to normal message routing, per the intentional, already-tested match_text_answer contract (not changed here).

Tests

5 new tests in src/bridge.rs:

• resync_parks_the_ask_with_no_live_resolver — confirms the gap resync_pending_asks leaves (pending_ask set, ask_resolution None).
• resync_text_answer_resumes_the_parked_run_instead_of_starting_a_new_one — the core regression test: asserts api.chat_calls/execute_calls stay empty after a matching text answer (i.e. no new run), and that subscribe happens before respond, exactly like the live path. I sanity-checked this test fails (times out) against the pre-fix fallthrough behavior.
• resync_callback_answer_resumes_the_parked_run_instead_of_starting_a_new_one — same regression, via a button press.
• resync_pre_restart_button_nonce_is_stale_and_reports_expired — a stale pre-restart nonce still gets the "expired" ack, not a silent new run.
• resync_answer_marks_the_chat_busy_and_drains_a_message_queued_behind_it — busy/queue semantics around a resync resolution.

Test plan

• cargo fmt --check
• cargo clippy --all-targets (no new warnings)
• cargo build --tests
• cargo test — 182 passed, 0 failed (177 lib + 5 main)