RTC probe assumes 24-hour mode: an RV3028 left in 12-hour mode is misread or never adopted #34

Found by local review of work/rak4631-rak12002-rtc (fork issue #4), 2026-10-03. This is pre-existing in dev. The branch only makes it reachable on the RAK4631, by declaring the RV3028 there.

rtc_probe() in zephcore/adapters/clock/ZephyrRTCDiscover.c assumes 24-hour mode. It masks the hours byte with & 0x3F and checks it as BCD 0-23. It never reads or sets the chip's 12/24 setting, and zephcore_rtc_save() never clears it.

On an RV3028, 12-hour mode is the 12_24 bit in Control 2 (10h). That is a RAM register, so it survives an MCU reset for as long as the chip keeps power, which on a RAK12002 means its supercapacitor. If firmware that ran before ZephCore left it set, then in 12-hour mode the hours byte holds AMPM in bit 5 and 1-12 below it:

• 1 PM to 3 PM (0x21-0x23) pass the BCD check as 21:xx-23:xx. The time is restored wrong by 8 hours or more, and logged as "restored".
• 4 PM to 11 PM (0x24-0x31) fail the BCD check. With the power-loss flag clear, the chip is not adopted at all, so no sync corrects it, and the 12-hour setting is never cleared.

The other descriptors have the same exposure wherever their chip has a 12-hour mode.

Suggested direction

On adoption, put the chip in 24-hour mode (on the RV3028, clear Control 2 bit 12_24), as MeshCore does with set24HourMode(). Otherwise, decode AMPM when the chip reports 12-hour mode. Either needs a per-chip register, much like the rv3028-eeprom-config property on that branch.