Swift SleepStagerV2 clips shuffled streams before defensive sort #67

Summary

Swift SleepStagerV2.stageSession applies binary-search window clipping to the caller-provided stream order, then sorts only inside the uncached recipe. On shuffled public inputs the binary bounds discard valid rows before the defensive sort. Android sorts each stream before clipping and is order-invariant.

Affected public entry point:

• SleepStagerV2.stageSession/6

Native RED/control evidence

Tested at fork commit 6df88d0d5d3398fcb4fec62c6cb3b23da3380dae with an isolated env-gated probe. The fixture supplies identical gravity/HR/RR rows in chronological order and in a deterministic even-index-then-odd-index permutation. The 90-minute requested window has 600-second input padding on each side.

Swift RED:

• sorted output: 0:5400:light
• shuffled output: 0:4330:light, 4330:5400:rem

The mirrored Kotlin probe is GREEN; the complete Kotlin probe class passed 4/4 with BUILD SUCCESSFUL. This confirms a platform drift rather than a fixture ambiguity.

Acceptance

• Swift clips only after establishing timestamp order, or otherwise uses an order-independent safe window selection.
• Sorted and deterministic shuffled forms of identical grav/HR/RR streams produce exactly equal segments.
• Existing sorted-input behavior remains byte-for-byte unchanged.
• Clipping continues to bound fingerprinting and recipe allocations to the required window.
• The isolated mirrored probe passes on Swift and remains green on Kotlin.
• Differential rollout for SleepStagerV2.stageSession/6 remains halted until resolved.

This is separate from #43 (the quarantined V2 pad-boundary decision).