Merge lane: runners wait for the merge without polling

Under the merge lane, a runner that has reported its PR with `task_pr_queue` keeps its slot and its Opus session for 20–30 min, polling `jaah-forge pr view` every ≥60 s until the lane merges it. Measured on main 2026-10-17: Task 6695 (#5630) reported at 17:39Z, merged ~18:06Z, settled 18:11Z, with agentic_seconds 4220 of 4252 total; Tasks 6672, 6709 and 6712 are similar. Tokens and slots are burned on waiting. Ask: - When the lane merges a PR, the control plane delivers "merged #N <sha>" into the runner's pane, the same way it already delivers lane failures (`deliver_message`). - The lane rewrite in `apps/api/app/dispatch_compose.py` `_MERGE_LANE_REWRITES` tells the runner to wait for that message after reporting, not to poll. It keeps one slow fallback poll (e.g. 10 min) in case the message is lost. - Optional, if it is clean: let the runner release its slot after reporting and be relaunched only on a lane failure or merge. Pick the simpler design and record the choice. Out of scope: the lane's batching or gate; the forge guard. Done means: - With the lane ON, a runner's transcript shows no `pr view` poll between reporting and the delivered merge message, apart from the fallback. - Settle latency after merge drops to under 1 min, plus any deploy watch the project requires. - Lane API and dispatch_compose tests cover the new message and the rewritten prompt; `./dc check full` green.

Lane now types "Merge lane: merged #N <sha>" into the runner pane; lane prompt waits on it with one 10-min fallback timer, no polling. Slot kept (simpler). Quick gate + 839 tests green; #5659 merged by lane (f15e3e4); deploy superseded. Draft 6795 filed.