Merge lane: a PR in a testing batch stays

On main (2026-10-17), lane run 6904 took 12 PRs. During its gate, 8 of their runners pushed new heads (rebases after a conflict notice, or unprompted), and each push superseded the row out of the in-flight batch. The run ended up gating 4 PRs; the other 8 went back to the queue after paying for nothing. History 21:03–21:17Z: #5694, #5695, #5699, #5700, #5702, #5703 and #5704 superseded mid-run. Ask: 1. When a batch takes a row (`queued → testing`), the CP delivers to the runner's pane (`deliver_message`, as lane failures and merges already are): "#N is in a lane batch — do not push until the lane reports". 2. The lane runner rewrite (`apps/api/app/dispatch_compose.py` `_MERGE_LANE_REWRITES`) states the rule: after `task_pr_queue`, push only after a lane failure or conflict message, never to "stay up to date". 3. The early-conflict notice (Task 6773, #5672) goes only to `queued` rows, never to a row that is `testing`. 4. A re-report of a `testing` row with a new head: keep superseding it (the head the lane pinned is gone), but record `superseded while testing` on the row, so the console and the run outcome show the churn. Out of scope: auto-merge disarm (Task 6906). Done means: lane and dispatch_compose tests for 1–4; on a live batch, no runner push while its row is testing; `./dc check full` green.

Runners now get a pane message when a lane batch takes their PR. The lane prompt now says to push only after a lane failure or conflict message, conflict notices reach only queued rows, and rows superseded while testing are noted and counted per run. PR #5716 merged (e5e69d5). My local full gate failed on an e2e test this change broke; develop has since fixed it in Task 6899. Deploy was superseded. UI check done; the clipped outcome is filed as draft Task 6920.