fix(bridge): subscribe before respond on ask resume; edit answered ask to ✅; separate resumed text

[bigduu]

Fixes #6 — final reply never renders after an ask is answered.

Root cause

render_until_settled resolved an answered ask as respond → subscribe. A server-side resubscribe (bamboo ws_v2::subscribe) REPLACES the channel's forwarder and takes a fresh broadcast-bus cut — nothing is replayed. So every event the resumed run emitted between POST /respond and the subscribe frame was lost; and when the WS was mid-reconnect (Subscribe commands queue unprocessed during backoff), the WHOLE resumed run through Complete could land in the gap. The new receiver then never yields, the render task waits forever, the status card stays '⏸ Waiting for your input…', and the final reply never renders — silently, exactly the #6 symptom. The button-callback e2e (2026-07-15) won this race by milliseconds, which is why it rendered while the earlier text-path run didn't.

Fixes

1. Subscribe BEFORE respond — the same subscribe-before-execute invariant the initial run already relies on (module doc's mapping table / ARCHITECTURE.md). A failed subscribe still records the answer (old degradation path preserved: dropping the user's decision is strictly worse than rendering nothing).
2. Answered-ask edit — the ask message is edited to {ask text}\n\n✅ {answer} (best-effort, edit_message-gated). Closes the follow-up gap noted on bridge: final reply never renders after an ask is answered — run resumes and completes at bamboo, chat shows nothing #6: the chat shows what was chosen, and the now-stale buttons can't be pressed again. render_ask returns the sent MessageRef instead of discarding it.
3. Resume paragraph break — StreamingRenderer::resume inserts \n\n between pre-pause text and the resumed run's tokens; previously the final reply glued onto the question (Pick one:OASIS), reading as missing even when the race was won. finalize_success trims trailing whitespace for the no-more-tokens case.

Tests

• paused_run_renders_buttons_with_nonce_and_resolves_via_callback now asserts cross-method call order [subscribe, subscribe, respond] via a new ordered op log on FakeBambooApi (the per-method vecs can't see interleaving), and that the ask message got the ✅ Approve edit.
• streaming_mode_resume_keeps_editing_the_same_status_message now pins the separator.
• Fake buttons_and_edit_capabilities() actually sets edit_message: true as its name always claimed, so the callback-resolution test exercises the streaming renderer.

Not fixed here (separate issue to file): resynced asks (resync_pending_asks) are parked without an ask_resolution sender, so an answer after a magpie restart falls through try_resolve_pending_ask into the normal message path and starts a new run instead of resolving the parked question.

https://claude.ai/code/session_014iw5PBsSzDFHus1GfkAK4y