[ryanbr]

Reported in #1937.

What is happening

Staging is not failing. From the report's own diagnostics:

sleep-detect summary: sleepRuns=5 droppedMinSleep=5 kept=0
detectedSpanMin=298 survivingSpanMin=0 sparse=false

The detector found 298 minutes of sleep across five runs, and dropped every one, because each run individually fell about a minute under the 60-minute minSleepMin floor. Five runs averaging 59.6 minutes, so a whole night of real sleep scored nothing.

Why the existing rescue declined

bridgeSparseSleep exists precisely to re-stitch runs fragmented by gravity dropouts. It was switched off, because it is gated on the night being sparse (#308 kept a dense night's original path byte-for-byte) and this night was dense: gravity coverage on the reporting device was 99.9%, and 48% on mine.

The rescue was declined because the data was good.

The change

The bridge also runs when the night is fragmented to nothing:

internal fun isFragmentedToNothing(sleepRunSpansS: List<Long>, minSleepS: Long): Boolean =
    sleepRunSpansS.size >= 2 &&
        sleepRunSpansS.none { it >= minSleepS } &&
        sleepRunSpansS.sum() >= minSleepS

The safety property. The gate is deliberately "today's answer is zero". If any single run already clears the floor the predicate is false, the sparse rule decides exactly as before, and a night that currently scores cannot change. It can only turn nothing into something.

Two runs at minimum, because one fragment is not a fragmented night. The sum must clear the floor, so a handful of brief stirs does not become a night. And the bridge's own rules still apply underneath: a gap over sparseBridgeGapMin, an intervening active run that is too long, or HR above the sleep band all still refuse. This enables the attempt; it does not weaken what the attempt checks. One of the tests pins exactly that, by giving a fragmented night a 10-hour gap and asserting the bridge still declines.

The predicate is deliberately not passed to buildRuns, which takes its own sparse flag for the HR-vouched gap rule. That decides how runs are formed, so widening it would change the input to everything downstream, including nights that currently score. This only re-stitches runs that are already built, and only when every one of them was about to be discarded.

Diagnostics

The E10 trace line now carries both gates as their own k=v keys (sparse=false fragmentedToNothing=true), rather than one flag naming the winner. It used to hardcode sparse=true, which since this change could print next to a summary line saying sparse=false: the kind of quiet disagreement that costs a reader an hour. Emitting both keeps the key set identical on every night, which is what a reader diffing two nights, and any k=v parser of the detail field, needs. Both platforms pin the rendered fragment sparse=false fragmentedToNothing=true gapMin= so the two languages cannot drift apart in silence.

Tests

Swift and Kotlin twins covering the reported five-fragment night, the safety property (a night with one qualifying run is untouched), brief stirs declining, a single short run declining, and the bridge's own gap rule still refusing.

Plus an end-to-end test on both platforms, which is the only one that proves the change does anything: it runs the reported shape (five 59-minute sleep runs, continuous gravity so the night is dense, four stirs the bridge has to chain through) all the way through detectSleep, and asserts both that a session now appears and, via the trace, that the rescue is what produced it.

That last assertion exists because the first version of this test passed for the wrong reason. With 3-minute stirs, mergePeriods (which absorbs any run under mergeMin = 15 and rejoins the same-stage neighbours) swallowed them, so the night arrived as one 306-minute run that always scored: sleepRuns=1 kept=1. The fixture was never fragmented and the code under test never ran. The stir is now 20 minutes, which is above mergeMin and below sparseBridgeActiveMaxInBandMin, and the anti-vacuity assertion makes that failure mode impossible to reintroduce silently.

Android suite green locally: 666 classes, 5625 tests, 0 failures. Swift is CI-verified.

The two existing "dense night has no sparse-bridge line" trace tests still pass, but their names and comments asserted density as the reason. Since a dense night can now open the bridge, they are repinned to the real invariant: this night is dense and its single run clears the floor, so neither gate opens.