[ryanbr]

@bartmuskala reported the caption dates on the Sleep page three times. The first
two explanations I gave were wrong. This is the third, with his own table as the
test.

The cause

The carousel groups nights by localDayString(endTs), so every row IS one wake
date and the rows are unique by construction. The date printed beside them came
from the ONSET, and a night that begins after midnight has its onset on its own
wake date. Two adjacent rows then print the same date while counting correctly:

Last night      Mon 14 Sep
1 night ago     Sun 13 Sep
2 nights ago    Sun 13 Sep   <- the after-midnight row, repeating the one above
3 nights ago    Sat 12 Sep

The change

A night is dated by its wake day minus one, the same key the row is selected by,
so a repeat becomes impossible rather than unlikely. The times stay the true
onset and wake, so such a night reads Sat 12 Sep · 00:30 - 07:00: the night of
Saturday into Sunday in the ordinary sense, reported exactly when it ran.

minusDays(1) on the zoned date rather than wakeTs - 86_400, because across a
DST boundary the day is 23 or 25 hours long and the arithmetic form lands on the
wrong calendar date.

What I got wrong twice, since it shaped the fix

1. I said the list was uniformly one day out, label from the wake end and date
   from the onset end. His table ruled that out: a uniform offset cannot print
   the same date twice, and his did.
2. I said the repeat was the borrowed-date defect and that sleep: date the browsed night, not the newest one, in the nav header #2201 had settled it,
   adding that no design decision remained. sleep: date the browsed night, not the newest one, in the nav header #2201 was real and separate and it
   landed. This survived it, which his 11.7.0 table showed by keeping the
   duplicate and moving it down a row while naming the same night.

I also called an after-midnight night looking out of sequence "one case that
looks wrong but is not". That was this bug, dismissed in advance. The reporter
was right all three times.

Tests

afterMidnightNightDoesNotRepeatTheDateAboveIt_issue2199 is his Tuesday table.
It asserts no two rows may share a date rather than only checking four expected
strings, because uniqueness is the property he actually asked for. Confirmed
failing before the change with the exact reported symptom:

row "2 nights ago" printed Sun 13 Sep · 00:30 - 07:00, expected it to start Sat 12 Sep

The earlier nightCaptionPairsEachLabelWithItsOwnOnsetDate_issue2199 could not
have caught this: every night in it crosses midnight, so onset and wake agree on
ordering.

navHeaderClockLabel_datesTheBrowsedNight_notTheNewestOne pinned the old anchor
in its own comment, on a 01:00 to 07:00 fixture, which is exactly this shape.
Repinned to the same shape rather than deleted, because the invariant it exists
for still holds: a stage-less night must not borrow the newest night's date.

Android suite: 6121 tests, 0 failures, 0 errors.

A regression found by re-reviewing this, and fixed in the second commit

clockLabel fills ONE slot from two branches: the session when the night
decoded, the daily metric's day key when it did not. The first commit moved only
the session branch.

Sleep rows are keyed by dayString(endTs), "the day its night ENDS on", so the
fallback prints the WAKE day:

night	before this PR	after commit 1	now
crosses midnight	disagreed already	still disagreed	agree
begins after midnight	agreed	DISAGREED	agree

A night would have read a day apart depending on whether its stages happened to
decode, which is the two-paths-one-night shape of #2201 that I had just told the
reporter was settled. Moving both ends together also repairs the cross-midnight
disagreement, which predates this PR and nobody reported.

A latent bug goes with it: the fallback parsed the day key at UTC midnight with
one formatter and rendered it in the DEVICE zone with another, so west of UTC it
already printed the previous day.

clockLabelNamesTheSameNightFromEitherBranch_issue2199 asserts the two branches
AGREE rather than pinning two strings, so it keeps holding if the anchor moves
again. Mutation-checked: reverting the fallback turns that test red and nothing
else. Suite now 6122 tests, 0 failures.

Apple, converged in the third commit

Android and Apple would otherwise name the same night differently where before
they agreed, so this now moves both.

Night.spanLabel renders a span when a night crosses midnight and a single date
when onset and wake share a day. The span already leads with the wake day minus
one, so it was right by construction. The single-date branch named the night by
its onset, which for a night BEGINNING after midnight is its own wake date:

1 night ago     Sun 13 → Mon 14 Sep
2 nights ago    Sun 13 Sep            <- leading with Sun 13 a second time

The same defect, presented more quietly. Because the strings are not identical
it reads as coincidence rather than a repeat, which is likely why Apple was
never reported while Android was, three times. The cross-midnight span is
untouched: it states both ends, and it was never part of the report.

Verified by compiling the label standalone with swiftc -O, since the app
target does not build on Linux:

row	before	after
Last night	Mon 14 → Tue 15 Sep	unchanged
1 night ago	Sun 13 → Mon 14 Sep	unchanged
2 nights ago	Sun 13 Sep	Sat 12 Sep
3 nights ago	Sat 12 Sep	Fri 11 Sep

StrandTests were NOT run locally. They need a Mac and the app target; CI
covers them on the build (Strand, macOS) leg. No new user-facing strings, so
no catalogue entries.

A test that would have passed here and failed elsewhere

The fourth commit. The Apple test first hardcoded "Sat 12 Sep", and
Night.dateFmt pins no locale by design, so it renders in the reader's. Expected
values now derive from a formatter carrying the same format and the system
locale applied to the wake day minus one, so the assertion follows the anchor
into any locale. The leading-date comparison also split on " →" rather than
taking six characters, which assumed English-width abbreviations, and hasPrefix
became exact equality, since hasPrefix would let a row leading Sun 1 pass
against an expected Sun 13 Sep.

Not included, deliberately

The parity ledger is unaffected: none of these files are scanned. KOTLIN_GLOBS
covers analytics, ingest, data, protocol and oura, not ui, and SWIFT_GLOBS
covers Packages/**, not Strand/Screens. Checked rather than assumed.

Nap and daytime-sleep rows do not flow through either label, so nothing that is
not a night is renamed.