BRC-149: Multicast BEEF object frame format

[jefflightweb]

This pull request:

Proposes a new standard by creating a new markdown file in the appropriate directory and requests discussion and assignment of a BRC number

Summary

BRC-149: Multicast BEEF Object Frame Format

Companion to #181 (BRC-148, the BEEF object plane). BRC-148 allocates the plane and, following the repo convention that frame formats are specified apart from addressing (BRC-124 vs BRC-129; BRC-143/BRC-144 vs their carriage rules), defers the concrete wire formats to a separate BRC. BRC-149 assigns FrameVer 0x09 and fixes the three byte layouts the plane needs.

The multicast object frame (FrameVer 0x09, assigned here — the next code after BRC-142's 0x08) is a 92-byte header plus payload that reuses the BRC-124 header at identical offsets, so existing classifiers, NACK retransmission (BRC-126), and fragmentation (BRC-130) require no changes. ContentID is SHA-256d(payload) (the reassembly and duplicate-suppression key, never the subject TxID); TopicID is SHA-256(topic name), occupying the field that carries the SubtreeID in transaction frames, and is the delivery-selectivity key; HashKey and SeqNum carry the flow semantics BRC-148 defines. The payload is the BEEF object verbatim, its leading version word (BRC-62 / BRC-95 / BRC-96) acting as an encoding-capability gate.

Two unicast records complete the plane. The submission record is the 0xBEEF-tagged envelope a publisher sends to operator ingress, naming one BEEF object to one or more overlay topics; on shared ports it is distinguished from a framed datagram (network magic 0xE3E1F3E8) and a bare transaction (BRC-12 / BRC-30) purely by leading bytes, which cannot collide. The delivery record is the envelope a delivery edge streams to a subscriber — TopicID, length, object verbatim. Both records exist because BEEF bytes are not self-delimiting without a full structural parse, which the fabric never performs; unlike the BRC-143/BRC-144 push lanes, BEEF lanes therefore carry an explicit length-carrying envelope.

Depends on #181 for the plane definition (the ./0148.md links resolve once it merges); the BRC-143/BRC-144 push-format references (#175/#176) are cited as in-submission. Index-row conflicts with #181 are expected and trivial (adjacent rows in README/SUMMARY/transactions README).

Changes: new transactions/0149.md; index entries in README.md, SUMMARY.md, transactions/README.md. No changes to existing BRCs.

[jefflightweb]

Marking this draft while we revise the BEEF submission-record design. The multi-topic submission record (topicCount 1..15) fans out one ingress object into up to 15 multicast frames, which — on the open/anonymous ingress class — is an amplification vector with no cost coupling. We're reworking so that multi-topic fan-out is an authenticated/metered capability and the open path stays single-topic. Will mark ready for review once the revision lands.