fix: end /next drains that re-offer an already-skipped message

[bandzalkin]

Problem

A room's /next catch-up loops could livelock, pinning the room's REST backlog behind one message forever (busy /next polling, no durable progress).

_retry_processed_ack (src/band/runtime/execution.py) deliberately converts an exhausted processed-ack retry budget into local completion: the turn ran, so re-running it could duplicate its side effects, and blocking forever on the failed ack would starve every newer message. But from that moment on:

• the platform copy of the message is unchanged (typically still processing), so /next keeps returning it as the oldest not-processed message;
• _process_backlog_message advances it from the local completed marker without touching the platform;
• _synchronize_with_next and _resync_pending_messages read ADVANCED as server-side progress and loop until /next yields None.

Result: a drain that spins on one message it can never retire, and a REST-only backlog that never gets past it. This also widens from a single trigger to whole bursts for agents that merge waiting messages into one turn (band-agent's merged turns ack every merged message on the turn's tools; one lost ack wedges one fetch each).

Fix

Classify the local-knowledge skips (locally completed, permanently failed, own echo) as a new BacklogProcessResult.NO_PROGRESS, and have both drain loops end a drain that re-receives a message they already skipped in the same pass — the same way the existing stopped and permanently-failed guards end a drain without durable completion.

Retryable outcomes are untouched: a handler failure with attempt budget left, a pending processed-ack, or an unacquired claim keep today's in-drain retry semantics (new test test_startup_sync_retries_failed_message_in_same_drain pins this; the guard records only NO_PROGRESS, never those).

Scope and limits

• Ends the local busy-poll livelock; startup/resync now complete instead of spinning.
• Does not make the wedged message durable on the platform — nothing can, once the ack endpoint keeps refusing it — and does not change the /next contract. New WS-pushed messages process normally while a wedged message waits to be retired (platform stale-processing re-serve, local completion cache eviction, or restart).
• No wire, persistence, or public API changes; BacklogProcessResult is internal.

Tests

• tests/runtime/test_resync.py: two wedge tests (repeating /next + locally completed message → both drains return synced after two fetches; they fail pre-fix by spinning to a 10-fetch cap) and the retry-preservation test.
• tests/runtime/test_execution.py: two local-skip assertions updated to the new NO_PROGRESS classification (behavioral assertions unchanged).
• Gate: ruff check, ruff format --check, pyrefly check, pytest full unit suite — 6703 passed / 711 skipped; pre-commit run --all-files clean.
• Review: adversarial round 1 confirmed a first-cut regression (guard recorded retryable ADVANCED results and deferred in-drain retries) → corrected by the NO_PROGRESS classification; adversarial round 2 traced all 13 result sites and every repeat class to bounded termination, zero findings; architectural pass approved the drain-loop ownership seam.

Found while reviewing band-agent's merged-turn work (ack path shared with ExecutionContext); no behavioral coupling to it.

[AlexanderZ-Band]

Closing as superseded by #761. Current main already detects a repeated locally nonrunnable /next head—including the locally completed state created when the processed-ack retry budget exhausts—and ends recovery after the repeat, preventing this drain from busy-polling.

This PR would duplicate that no-spin behavior. It also cannot unblock later REST-only work behind a server-retained head; that remaining recovery problem needs a separate, current-main design and is being considered in #730.