NetworkConnection: DATAGRAM offer 1400 but usableDatagramFrameSize returns 0 (FB25125957)

I am looking for guidance on the new Swift NetworkConnection<QUIC> DATAGRAM API. A Network.framework defect has not been established. I filed FB25125957, which includes a minimal reproducible source package and numeric evidence.

Environment

Apple Silicon M2, macOS 27.0.1 (26A434), Xcode 27.0 (27A266a), macOS SDK 27.0 (26A425), Swift 6.4. Builds use an explicit DEVELOPER_DIR, Swift 6 strict concurrency, and warnings as errors.

Apple-to-Apple localhost case

• Both endpoints offer maxDatagramFrameSize(1400), explicitly start their parent connections, and wait for ready.
• Fresh certificate mutual TLS uses a private test root, role-specific SAN validation, and preknown exact leaf pins. No system trust or keychain modification.
• After ready, the client awaits parent.datagrams, then reads usableDatagramFrameSize on that same parent. The accessor returns and the getter returns 0.
• Both endpoints passed their current TLS 1.3 / ALPN / certificate gates, with no early data. The server getter remained unobserved when our local guard stopped this case. No DATAGRAM payload was sent. Our capability error 1005 is a local guard, not NWError.

Independent-peer case

• One Apple listener and an aioquic 1.3.0 client, both advertising 1400, with the same current root/SAN/exact-pin authentication requirements.
• Both passed mutual authentication, TLS 1.3 / 0x1301 / exact ALPN, with no resumption or early data.
• The peer decoded Apple's remote max_datagram_frame_size=1400 (present) and recorded its own serialized offer=1400.
• On the same accepted Apple parent, await datagrams returned and usableDatagramFrameSize completed with 0.
• The peer's local serialization does not prove that Apple parsed its offer. No application DATAGRAM or media payload was sent.

Questions

1. Does ready guarantee that the peer DATAGRAM transport parameter has been processed? Does completing await parent.datagrams provide a stronger guarantee? If a zero usable capacity is transient, what supported event or API should be awaited rather than arbitrary sleeps/retries?
2. What is the supported start/ready/datagrams ordering and parent lifetime for outgoing versus accepted connections? Is opening a reliable stream first a prerequisite? Is there a minimal certificate-TLS DATAGRAM example?
3. Which public diagnostic can distinguish an absent/zero peer advertisement from usable-size calculation, interoperability, or lifecycle issues?
4. Is there a known limitation in this exact OS/SDK, a fixed version, or an authentication-preserving workaround?

The source and evidence are attached to FB25125957. They contain no private keys, passwords, pairing credentials, user footage, app bundles, or full qlog. I am asking about basic DATAGRAM availability, not claiming any Wi-Fi or video performance result.