[masarray]

Scope

Add the first focused Phase 4D-R2 tranche on top of R1. This introduces an allocation-free, association-aware BRCB control state machine before wiring MMS object attributes.

Implemented

• separate ephemeral MMS association_id from stable binary Owner identity
• owner-only reservation and control access
• reject reservation stealing by another live association, including a second association presenting the same stable Owner
• ResvTms disconnect retention and exact expiry
• same Owner may reclaim a retained reservation before timeout with a new association token
• association loss always disables RptEna
• ResvTms == 0 releases immediately on disconnect
• owner-gated RptEna, EntryID replay/resume/rewind, and PurgeBuf
• replay/purge rejected while reporting is enabled
• no TCP/IP dependency in the portable control core
• new GCC/Clang -fno-exceptions -fno-rtti multi-client hard-profile smoke
• hard-profile footprint and no-exception evidence includes the new binary

Deliberately not claimed yet

• MMS object-bank exposure for Resv, ResvTms, Owner, RptEna, EntryID, PurgeBuf
• propagation of association identity through static dispatcher callbacks
• persistence of ownership/replay state across reboot
• physical ESP32-P4 flash acceptance; remains READY_NOT_MEASURED

Next R2 tranche

Wire an explicit per-request association access context through the static connection/dispatcher path, then expose the BRCB operational attributes through MMS and add encoded multi-client hard-profile tests.

[masarray]

Closing as superseded by #51, which consolidated the cumulative BRCB R1–R3 server stack onto current main. The association-aware BRCB ownership work here is retained as tranche-level history, but this stacked PR is obsolete.