fix: cover the delayed Screen Broadcasting alert's full appearance window

[Timo972]

Problem

The post-stop sweep added in #24 waits only 2s for the "Screen Broadcasting" alert to appear, but SpringBoard publishes that alert well after the extension socket closes — measured ~5s after the stop on iOS 26.5, and ~10s (up to ~12s) observed on iOS 18 hardware. The sweep therefore regularly ended before the alert even existed. The leftover modal then blocks any app from foregrounding, so the next broadcast/start fails with:

408 The runner app could not be brought to the foreground to present the broadcast picker

The start dance could not recover on its own either: its stale-alert dismissal only runs inside the confirmation-sheet wait loop, which is only reached after foregrounding succeeded — and the alert is exactly what prevents foregrounding.

Changes

• Raise the appearance grace to 15s (plus a 5s dismissal budget on top) so it covers the slowest observed appearance with margin, and drop the @available(iOS 26.0, *) gate — the delayed alert is not an iOS 26-only behavior.
• Extract the sweep into a shared helper (sweepBroadcastStoppedAlertWithDismissLabels:...) that keeps the existing semantics: wait out the appearance grace, then re-dispatch the dismissal tap until the alert is observed gone. With zero appearance grace it degrades to a single existence probe.
• broadcast/start: clear a stale alert before the foregrounding attempts (zero-grace sweep), and when the fallback activation times out, sweep once more — if an alert was found (it had landed mid-dance and swallowed the activation), retry the activation once.
• broadcast/stop: on the nothing-to-stop path, run a zero-grace sweep so a leftover alert from a broadcast that ended without a stop call (crash, runner relaunch) is also cleared, while the idempotent no-op stop stays a single probe.

Verification (iPhone SE, iOS 26.5)

• Before: stop returned after 2.4s having seen no alert; the alert landed ~5s after the stop request; the next start 408'd until the alert was manually accepted.
• After: broadcast/stop logs the Screen Broadcasting alert appeared 5504ms into the sweep, dismisses it, and returns in ~6.4s with the screen clean; back-to-back start/stop cycles run without the 408; an idempotent stop returns in ~0.4s.
• Device and simulator test builds both succeed (the sweep paths are compiled out on simulator/tvOS as before).

🤖 Generated with Claude Code