M5 attestation race condition during catastrophic buffer pool draw

Scenario

During a catastrophic event, the registry initiates both a buffer pool draw (invalidating affected credits in buyer accounts) and a notifyInvalidation call to M5. M3's _attestationDistributed mapping shows the original attestation as distributed (preventing double-distribution) while the Foundation's buffer pool replacement creates new credits whose receiptHash differs from the original, potentially allowing double-distribution of the same underlying economic value.

Mechanism

M5 invariant M5.7 states 'invalidation does not unwind distributions' — correct for already-distributed inflows. But the buffer pool reversal generates replacement credits with new identifiers. If replacement credits generate new attestation receipts (different hash), M5/M3 could treat replacement-credit revenue as a new, unrelated inflow — producing double-distribution of the same underlying economic value in a catastrophic-event scenario.

Mitigation

Buffer pool reversal process must specify that replacement credits generate attestation receipts explicitly flagged as REPLACEMENT_FOR: [original_receiptHash]. M5 should check for this flag and mark replacement receipts as zero-revenue events. M3 should enforce that any receiptHash flagged as replacement generates no new recordInflow call. Requires coordinated update to both the buffer pool specification and the M5 state variables in modules.

Residual risk

Medium. Cross-spec race condition not addressed in either spec; could produce incorrect distributions in catastrophic-event scenarios — exactly when system trust is most important.