fix(acp): pace relay observer frames (6/s + 90/min, zero burst)

[tlongwell-block]

Problem

Starting a harness with many ACP workers replays the whole observer snapshot as a burst of kind-24200 EVENT frames. With 24 workers the snapshot is 73 frames (1 harness_started + 24×(acp_write initialize, acp_read response, agent_initialized)); plus 3 REQs and presence, that blows the relay's shared WS admission budget (50 events / 5 s, admission.rs × human_ws_events_per_sec = 10) and the relay answers with the countdown NOTICE Morgan reported:

rate-limited: quota exceeded; retry in 5s

Worse than the NOTICE: the rejected observer frames were silently lost (fire-and-forget publish), and the burst consumed budget that REQs/presence/user-visible publishes need.

Fix (harness-only, no relay deploy)

Pace the already-async observer publisher (spawn_relay_observer_publisher) through a dual-window gate, per the joint design debate in buzz-bugs:

• 6 frames/sec (167 ms interval), zero startup burst — even the first snapshot frame waits for its slot
• 90 frames / rolling 60 s governor — observer frames share the agent's 120/min LimitType::Messages budget with real chat messages; 90/min leaves ≥30/min headroom
• Snapshot drain and live tail both flow through the same gate; readiness, subscriptions, presence, and normal publishes are untouched (they don't go through this task)
• No retry/ACK queue. Overflow degrades to bounded delay via the existing broadcast buffer, then to the existing visible Lagged warning

Startup cost: the 73-frame snapshot drains in ~12 s of telemetry backlog delay only — agent initialization and readiness are unchanged (publisher task was already decoupled).

Note: the deployed-relay NOTICE-based adaptive rate gate already exists in the harness since #2199 (set_rate_limit_gate matches the rate-limited: prefix and defers REQs / drops ephemeral publishes) — with pacing in place it simply never trips in this scenario.

Validation

cargo test -p buzz-acp — 565 passed (includes 2 new paused-time pacer tests: no-burst spacing, rolling-minute cap). cargo clippy -p buzz-acp --all-targets and cargo fmt --check clean.

Live local test (per TESTING.md): tip-of-main relay, fresh migrated DB, real Redis admission limiter, 24 stub ACP agents with BUZZ_ACP_RELAY_OBSERVER=true, NIP-OA auth tag so observer frames route:

	baseline (main)	patched
rate-limited NOTICEs	27	0
buzz_admission_rejections_total	27	0 (unchanged counter)
observer frames fanned out	46 / 73 (27 lost)	73 / 73
agents initialized	24/24	24/24
frame spacing	burst	min gap 163 ms, max 6 frames in any 1 s window, 30 in any 5 s window, 73 in 60 s
snapshot drain time	—	12.2 s

The baseline reproduces Morgan's exact failure (27 rejections, matching the arithmetic from the debate thread); the patched build eliminates it with zero frame loss.

Design debate + consensus spec: buzz-bugs thread (Wren + Eva, 2026-07-18). Implementation is Wren's commit from wren/pace-observer-publisher (#2069) carried onto current main; #2069 is superseded by this PR.

[tlongwell-block]

Two correctness issues before approval:

1. RelayEventPublisher feeds observer kind 24200 through the generic RelayCommand::PublishEvent branch. Since fix(acp): honor relay rate limits and pace resubscribes on bad links #2199, that branch drops every event while rate_limit_gate is active (relay.rs:1352-1364); it does not slow this pacer. Thus any rate-limited: NOTICE (including one caused by unrelated functional traffic) makes the next ~5 seconds of paced observer frames disappear silently. At 6/s that is roughly 30 frames. This contradicts the agreed adaptive-backpressure/no-silent-loss behavior and the PR description's statement that fix(acp): honor relay rate limits and pace resubscribes on bad links #2199 already supplies it. Please make observer publishes wait through the gate (kind-aware, so typing can remain droppable), or otherwise connect the gate to this pacer without a retry/ACK queue.

2. The new comment says “Subscribe before pacing,” but the code still calls snapshot() before subscribe(). An event emitted in that gap is in neither the cloned snapshot nor a receiver's broadcast queue. Please reverse those two calls (let mut rx = observer.subscribe(); let snapshot = observer.snapshot();). This is a tiny race, but the change is specifically establishing loss-free snapshot-to-live handoff.

The moved-main turn-timeout/stall work does not otherwise intersect this publisher path: those changes only add/alter observer producers, while the publisher remains a detached task launched before readiness presence. The two paused-time pacing tests pass, and I independently ran the full package suite at the exact PR head: cargo test -p buzz-acp → 565 passed at 8e4a0d73ccfbfca4771661d66745997a1fa8c5ee (same-shell SHA check).

Current score: Minimalness 9/10, Elegance 9/10, Correctness 7/10. The reported live baseline/patched evidence convincingly covers the clean 73-frame startup case, but it does not exercise a NOTICE after pacing begins, which is where issue 1 lives.