[MattJackson]

Status row 132, piece 2 of 6: the connector's datagram driver. It presents the keying-material item to the webrtc framer (#795). This PR covers the accepting side; the dialling side and its candidate admission come next, in their own PR, under the ARCHITECT's row-132 ruling.

What

busbar-core-connector::datagram::DatagramFraming drives one association's datagram framer over the host's dtls engine (dtls::Association). Every call carries the datagram lane (abi::transport::datagram).

• Paths. Paths are host numbers. Each one is told to the framer once, and only for an address the secure layer knows: a verified check came from it, or core's own probe proved it. A spoofed source stops at the host.
• Terms. The rendezvous terms (role, both ends' check credentials, the far end's fingerprint) build the association.
• Keying material. The exported material crosses exactly once, on a call whose lane says verified = 1. It is then dropped, which zeroes it.
• Routes. A clear route is sent only where may_send_clear allows. A secured route is sealed to the bound path. Anything else is dropped and counted.
• Path requests. A path request binds only a proven path.
• Judging. Every answer is judged by check_datagram before any byte of it is used.
• No I/O. The driver is sans-IO: the port stays the caller's, so no_io_outside_hostio is unaffected.

Small additions:

• dtls: SrtpProfile::code (RFC 7714 registry code), Association::peer_verified, Association::knows.
• framer: Buffers sink/take and ready are now pub(crate).

Why

• BUSBAR-1.6.0.md l.758-766: the framer "gets the exported SRTP keys through the keying-material item", "application data waits for peer verification", and ICE migration "rebinds only on a verified round-trip check (a spoof is a RED)".
• Decision 1.5.5 MCP: plane boundary and the core route-auth table #45: busbar terminates WebRTC.

RED-able tests

In crates/busbar-core-connector/src/tests/datagram_tests.rs, a scripted framer runs over a real ring DTLS handshake against a second dtls engine.

1. The item crosses once, verified, and equals the far end's own exporter output. Plaintext flows both ways over the bound path. RED: presenting the item on every call, or never, fails the exact-once count.
2. A source that sent no verified check never reaches the framer, and no path is told for it. RED arm: the honest check crosses, with its path told.
3. A rebind to a path that never answered core's probe is not applied, and a clear non-answer route to it is dropped and counted. RED arm: once the path answers the probe, the move applies.
4. An answer that breaks the lane (a zero-length route) is a FAULT, and nothing is sent.
5. Nothing on the port is the association's before the rendezvous.

Ledgers

None touched. There is no new crate edge and no new third-party dependency (Cargo.lock is unchanged).