fix(tests): PairingCeremony poll tests stop racing the scheduler (#192)

[kpmmmurphy]

Closes the flake tracked in #192 (five hits in three days; the latest killed PR #201's CI twice in a row).

The two poll tests use a scripted transport that needs three 1 ms polls; the 5 s approvalWindow is only a deadline — but under swift test --parallel on the CI runner the actor hops alone can exceed it, and the ceremony then honestly reports "not approved" (5.6–6.8 s each hit). Sixty seconds keeps the deadline as a hang guard without racing the scheduler. Test-only change; the ceremony itself is untouched.

🤖 Generated with Claude Code

https://claude.ai/code/session_01K2kJAPEHTFU34uKiGArFSP

[netlify]

✅ Deploy Preview for m1k3 canceled.

Name	Link
🔨 Latest commit	5feda56
🔍 Latest deploy log	https://app.netlify.com/projects/m1k3/deploys/6a99ed156719b3000886f826

[claude]

Reviewed against the checklist in macos/CLAUDE.md / repo CLAUDE.md. Test-only diff (macos/Tests/M1K3BrainLinkTests/PairingCeremonyTests.swift, +7/-2), no production code touched — confirmed via gh pr diff.

Correctness — looks right. I read PairingCeremony.pair (macos/Sources/M1K3BrainLink/PairingCeremony.swift:151-181): the poll loop is while clock.now < deadline { ... try? await clock.sleep(for: pollInterval) }. approvalWindow is genuinely just a deadline, not an assertion that anything must happen by a certain time — the scripted transport in happyPathPairsAfterApprovalPollSucceeds and secondHostIsTriedWhenTheFirstIsUnreachable only needs 2-3 polls at 1 ms each to drain its script and return .paired. Widening the window to 60 s can't change what those tests assert; it only removes the chance that swift test --parallel actor-hop scheduling (documented: 5.6–6.8 s observed) pushes clock.now past a 5 s deadline before the script drains, which was turning a real pass into a false "not approved" .failed. That's a legitimate root-cause fix, not a broadened assertion or a sleep-and-hope band-aid.

Scope is correctly narrow. The two tests changed are exactly the ones that poll-to-success and are timing-sensitive. approvalWindowExpiryFailsCleanly (line 155) correctly keeps its short .milliseconds(50) window — that test's whole point is exercising expiry, so shrinking-not-widening is right there and it's good this PR left it alone. macRejectionSurfacesItsMessage and noHostsFailsWithGuidanceNotAHang also keep their short windows, correctly, since neither ever reaches the poll loop (both return before onPhase?(.awaitingApproval)).

Provenance. The new Review: block (lines 14-17) is appended, not rewriting the existing Signed: block from 2026-08-24 — follows the MurphySig append-only convention correctly, and the in-file rationale matches the PR description.

Minor, non-blocking: 60 s is a big jump from 5 s (12x). If PairingCeremony's poll loop ever regresses into an actual hang (e.g. a future change makes the scripted transport never satisfy the loop), these two tests now take up to 60 s each to fail instead of 5 s, which is a slower feedback loop in that failure mode. Given the stated goal is "keep the deadline as a hang guard," something like 15-20 s would likely give the same anti-flake headroom (the observed overruns topped out at 6.8 s) while keeping a genuine-hang failure faster to notice. Not asking for a change — the tradeoff as chosen is reasonable and well-justified by the 5-flakes-in-3-days data — just flagging it as a knob that could be tightened if CI timeout budget ever becomes a concern.

Overall: solid, well-scoped, well-documented flake fix. No concurrency, architecture, MLX, or persistence concerns since it doesn't touch any of those seams.