RTC probe adopts a chip whose status-register read failed, then writes time into it #23

Found while reviewing the hw CLI (#1, #16). This is pre-existing code from upstream dev that neither PR changes.

Problem

rtc_time_unreliable() in zephcore/adapters/clock/ZephyrRTCDiscover.c returns true when the status-register read fails ("can't confirm => don't trust it"). rtc_probe() accepts a candidate whose time block is valid BCD or for which rtc_time_unreliable() returns true. So a chip that answers the 7-byte time read with non-BCD data, and then fails the status read, is accepted as an RTC. The first such chip becomes the write-back target (s_active). Every later time sync then calls zephcore_rtc_save(), which writes seven bytes at that chip's time register and read-modify-writes its status register.

The acceptance-on-power-loss rule exists for a good reason: a battery-depleted RTC holds garbage time with its power-loss flag latched, and it must still be adopted so a sync can re-initialise it. But a failed status read is not that flag. It is the absence of evidence, and it is treated as proof the chip is an RTC.

When it matters

Only on a board that declares an RTC candidate at an address shared with a non-RTC part, where that part answers the time read but not the status read. The RAK4631 used to declare the DS3231 at 0x68, an IMU address; #1 now declares only the RV3028 there (see #4). Other boards that include all of rtc-i2c.dtsi are the ones to check.

Suggested direction

Accept on a power-loss flag that was actually read as set. On a failed status read, skip the candidate (or leave it unprobed) rather than adopting it. That would change upstream behaviour, so it would go to liquidraver/ZephCore as its own PR, with the maintainer's go-ahead.