"Cut after this airs": scheduled safe cut for match-end reactions

[Soulhackzlol]

What

A new ⏱ Cut after this airs button, visible while a delay is active. Press it the moment your match reaction ends: InstantClone records that exact live-edge timestamp, lets everything up to it reach your viewers, then fires the normal IDR-aligned cut to live on its own.

Why

The whole point of running a competitive delay is stream-snipe protection, but ending it gracefully was manual: finish the match, react, then count 30 seconds in your head before hitting Cut so the reaction isn't clipped off the delayed output. Get it wrong in one direction and viewers lose the reaction; wrong in the other and you sit on a dead delay. Now it's one press at a moment you already recognize.

How it works

• The controller stores the live-edge input timestamp as a mark. Each egress pump's throttled cut-check calls maybe_fire_safe_cut, which fires only when the slowest live destination has aired past the mark, so a fast destination can never cut a slow one short of it. A compare-exchange makes exactly one pump the firing pump; the cut itself is the same stop_delay -> compute_delay_cut path as a manual Cut, so it inherits the IDR alignment and connection preservation.
• The mark clears on manual Cut, on disarm, and on a fresh OBS publish session (the mark belongs to the old session's timeline and could never be reached on the new one).
• New endpoints: POST /cut-after (409 when no delay is active) and POST /cut-after/cancel. /state gains safe_cut_pending and safe_cut_remaining_ms.

UX

• The button lives under the Cut button and only exists while a delay is active. While a mark is pending it becomes a live countdown ("auto-cut in ~27s"), and tapping it again cancels without cutting.
• A pure-CSS hovercard (works with keyboard focus too) explains the trick with a press -> reaction airs -> auto-cut -> live timeline.
• The setup wizard teases the flow before the first stream, and the onboarding tour's Arm/Activate step documents it.

Verification

• cargo fmt --check, cargo clippy --all-targets -- -D warnings, and cargo test --release all clean: 234 passed (5 new controller tests: refusal without an active delay, schedule/cancel round-trip, slowest-consumer firing gate, clearing on manual cut/disarm, clearing on publisher reconnect).
• New e2e scenario F runs the real thing: ffmpeg publishes live, the script arms and activates a 2s delay, checks the 409 refusal, schedules and cancels without cutting, then re-schedules and asserts the proxy auto-cuts back to passthrough with the sink's connection intact (exactly one publish accept). All 6 e2e scenarios pass locally.