Phase 4D-R3: persist retained BRCB replay history and recovery cursor

[masarray]

Scope

Stacked on Phase 4D-R2d. Upgrade BRCB recovery state from undelivered-only v1 semantics to a replay-capable v2 image while retaining v1 restore compatibility.

Recovery state v2

• persists the entire retained BRCB ring, including reports already delivered but still replayable
• persists independent delivery_offset
• persists replay_gap
• preserves next_entry_number, sequence number, dropped-report counter, EntryIDs and buffered PDUs
• keeps live RptEna, pending BufTm coalescing, association ID, Owner and reservation connection state transient
• restore always returns reporting disabled

Compatibility

• encoder emits ARBRCBQ2 / state format v2
• restore accepts both v2 and legacy ARBRCBQ1 / v1 images
• legacy v1 naturally restores as an all-undelivered queue because v1 never stored delivered replay history
• A/B checkpoint wrapper format remains unchanged; the state image is opaque to the journal envelope

New hard-profile recovery oracle

Proves under GCC/Clang -fno-exceptions -fno-rtti:

• delivered E1 remains replayable after reboot while normal delivery resumes at E2
• explicit rewind/resume works against restored history
• handcrafted legacy-v1 image still restores
• overflow replay_gap and dropped-report counter survive reboot
• purge is durable across reboot
• purge does not roll EntryID backward; next report remains monotonic (E5 in the test)

Physical hardware gate

This does not claim physical ESP32-P4 flash acceptance. The board-level geometry/latency/endurance/power-loss evidence remains READY_NOT_MEASURED until real hardware output is captured.

[masarray]

Closing as superseded by #51, which landed the cumulative BRCB R1–R3 recovery/persistence stack on current main. This R3 tranche remains historical evidence rather than an active merge candidate.