d7114fc6e2
Three latent spec divergences that only surfaced once we fed the Marmot stack with a Welcome authored by openmls 0.8 (the MLS backend under MDK / whitenoise): * ratchet_tree extension type was 0x0001 (RFC 9420 §13.3 assigns 0x0001 to application_id; ratchet_tree is 0x0002). Welcomes and GroupInfos Amethyst emitted were unreadable to any spec-compliant peer, and Welcomes from peers couldn't be joined because the tree lookup failed. * external_pub extension type was 0x0003 (that slot is required_capabilities; external_pub is 0x0004). External commits would have failed interop the same way. * sender-data ciphertext_sample used AEAD.Nk (16 B) bytes of the ciphertext; RFC 9420 §6.3.2 mandates KDF.Nh (32 B). Every cross-implementation PrivateMessage would fail sender-data AEAD. Amethyst ↔ Amethyst round-trip tests passed because both sides were wrong the same way — the existing MlsConformanceTest hard-coded the wrong extension IDs, so it even asserted the broken invariant. Conformance test assertions updated to the spec-correct values. https://claude.ai/code/session_01HfHdd5S5rvxUW2ihEpLGJr