[masarray]

Scope

Start the post-Phase-4C BRCB operational-semantics tranche as a focused stacked PR on top of the ESP32-P4 working branch.

Implemented in R1

• split retained BRCB history from the active delivery cursor
• successful delivery no longer destroys the retained snapshot
• add replay_from(EntryID)
• add resume_after(EntryID)
• add rewind_to_oldest()
• add runtime purge_buffer() primitive for future PurgeBuf MMS exposure
• distinguish queue_size() (pending delivery) from retained_size() (replay window)
• surface replay_gap() when bounded-buffer pressure evicts an undelivered entry
• preserve dropped_reports() for actual undelivered loss instead of ordinary eviction of already-delivered history
• keep checkpoint format v1 backward-compatible by persisting only the pending-delivery suffix; delivered replay history remains volatile until the explicit R3 persistence-format tranche
• extend the no-exception/no-RTTI BRCB hard-profile smoke with replay/resume/purge/overflow assertions

Deliberately not claimed in R1

• BRCB Resv / ResvTms / Owner association ownership
• MMS object exposure for EntryID selection or PurgeBuf
• persistent replay cursor/history across reboot
• physical ESP32-P4 flash geometry/latency/endurance acceptance (still READY_NOT_MEASURED)

Next stacked tranches

1. R2 — association ownership/reservation and BRCB MMS object bank; enforce owner-gated RptEna, EntryID selection, and PurgeBuf, with multi-client hard-profile tests.
2. R3 — versioned persistence/recovery policy, checkpoint replay cursor/history as explicitly designed, hardware flash evidence gate, and physical power-loss/latency acceptance.

This PR intentionally stays draft until BRCB hard-profile, embedded-hard-profile, C++ CI, security/evidence, and ESP-IDF compile gates are green.

[masarray]

Closing as superseded by #51, which consolidated the cumulative BRCB R1–R3 server stack onto current main. This tranche remains useful as implementation history, but it is no longer an active integration line.