Android computes five connection readouts it never shows, and the clock one may be the wrong shape #2091

What

Five ConnectionReadout functions are implemented in the Kotlin twin and covered by ConnectionReadoutTest, with no production caller anywhere in the Android app:

• clockLatchedLabel
• rtcWarning
• sessionRows
• drainedRowsFromSummary
• lastFrameLabel

Android's entire production use of ConnectionReadout is uptimeLabel, reconnectCount, lastOffloadResult, linkEpitaph and linkBankedSummary. macOS renders all of the above: its Test Centre connection panel shows seven rows plus the plain-words RTC warning, and its Devices card carries the clock line and warning on the active strap.

So an Android user whose strap clock was never set can only learn that by exporting a log and reading the verdict token themselves. On #1313 that is exactly what happened: the cause was found by reading Heal #547: purged ... implausible timestamp (bad strap clock detected) out of an exported zip, then asking the reporter to guess whether their strap's time was wrong.

Android also misses the #1818 nuance as a result. The log-only clock verdict says "charge to 100%" unconditionally, while rtcWarning tells an already-charged strap that charging again will not help and to export a log instead.

The design question to settle first

"Clock latched" is a yes/no built on the 1970/71 ceiling, so a FUTURE-dated clock reads "yes". #1313 was future-dated, which means the readout as it stands would have looked healthy on the one Android case on record.

clockVerdict already exists on both platforms, already separates FUTURE-DATED / RTC-EPOCH / CLOCK-WARNING / clockOk, and is already computed on Android for the log line. The readout probably wants to be that verdict rather than a latched yes/no, on BOTH platforms, which makes this a parity change rather than an Android wiring job.

Prior work

PR #2089 wired the clock pair into Android's Test Centre and Devices card and was closed unmerged for the reason above. Its branch fix/android-clock-latched-readout is left in place: the plumbing it added (LiveState.strapNewestUnix, published where GET_DATA_RANGE is already parsed, cleared with the link the way macOS clears strapRange) is the prerequisite whichever shape the readout takes. Its review also found the traps: gate the row to the ACTIVE card, pass a battery reading only from the current link, and do not make the Devices screen subscribe to the log revision.

Not yet exercised against a strap with a broken RTC on either platform.