docs: fix what a review of the second correction pass found

Third and final correction round. Two reviewers went over 4a9fe0c; one
approved the PR outright, the other found that the rewritten acknowledgement
rule had picked up a new wrong qualifier.

The acknowledgement rule, once more. Calling the identity bindings
"post-decrypt" is wrong for the session slot binding, which runs before any
AEAD precisely because every failure the MLS library raises below it happens
before it authenticates anything. R2 of the same document already said so. The
bullet also named three identity bindings where the code and
delivery-and-acks.md name four. Both fixed, and the policy row now says its
acknowledgement is an arrival-path rule: a frame that reaches the group buffer
and later resolves as a policy refusal is never acknowledged, which is what
group-message-lifecycle.md says one file over.

R1 understated a forged membership answer. The members cache it corrupts also
feeds the sealed rich payload gate, which requires every non-self member to be
known rich-capable. An attacker-chosen identifier is not, so the gate closes
and reply context and forward attribution move from inside the MLS AEAD to
hop-visible cleartext while media secrets are dropped. That defeats a control
this document lists by name, reached by the adversary that control names.

The spec claimed a working relay-side remove path. The check is right and
required, but a genuinely relay-originated remove is injected unattributed, so
its sender can never be an administrator and the frame is always dropped:
relay-native remove reconciliation is inert, and the live path is the removing
administrator's own signed notification. Stated as the consequence of the rule
that it is.

Recovered the one thing the restructure actually lost: the leaf identity
binding's mutation-check inventory, ten named sabotages plus the adversarial
fixture behind the mls crate's test-utils feature, without which the use-time
seam cannot be tested at all. ADR 0010 also gains the adopt-path ordering rule
and the "what would undo this" section every other ADR carries.

Also: the BLE fallback caveat swept into its two restatements, R9 no longer
claims a design nobody can point at, the outbox repark edge qualified to plain
DMs, and C5 notes that C6's retry fallbacks are a fifth set of the same shape.

Author: bahdotsh

CLAUDE.md

@@ -132,7 +132,9 @@ These fail silently if broken. Each is documented in full where it is linked.
 - **Adding a control-message prefix** means adding it to the registry that
   drives injection prevention
   ([spec](docs/spec/control-messages.md#reserved-prefix-registry)).
-- **Never add a catch-all arm to a telemetry reason classifier**
+- **Never add a catch-all arm to a telemetry reason classifier that matches on
+  an enum** (a classifier over an open wire string may, if the fallback returns
+  a fixed token and never the input)
   ([ADR 0013](docs/adr/0013-exhaustive-privacy-classifier.md)).
 
 ### Safety rules

docs/adr/0010-unconditional-leaf-identity-binding.md

@@ -108,3 +108,22 @@ delivered it, so it names **this device** as the subject, and the remedy it
 implies is to abandon the group rather than to evict a member. The leaf cannot
 speak, but it holds live group secrets and reads everything, which no later
 refusal undoes.
+
+The adopt path's ordering carries the same weight as the checks themselves: the
+forged-tree test MUST run **before** the duplicate-session check. The adopt is
+stage-then-replace and refuses non-destructively (`join_group_replacing`), so an
+existing session survives the refusal; in the other order the forgery is
+swallowed as a harmless retransmit. It is the opposite of harmless, and reaching
+it needs only that a session with the peer already exists, which is either half
+of a both-create race or any re-invite.
+
+## What would undo this
+
+Deleting an arm that looks redundant. Each of the four commit-walk sources and
+each seam was individually proven load-bearing by mutation testing: the binding
+is checked against ten named sabotages, each removing one arm and expecting the
+suite to fail. The adversarial fixture that seats a forged leaf directly into a
+key store, bypassing both entry gates, is
+`MlsManager::seat_forged_leaf_for_testing`, behind the mls crate's `test-utils`
+feature. Without it the use-time seam cannot be tested at all, because no honest
+code path produces the state it defends against.

docs/security/threat-model.md

@@ -152,15 +152,21 @@ The rule the protocol settled on:
 
 - A frame refused on **security** grounds gets **no acknowledgement**, and its
   identifier is unmarked. That covers the signature gate, inbound plaintext
-  refused by encryption policy, and the post-decrypt identity bindings (sender,
-  session and leaf address mismatch), which are intercepted *before*
-  classification precisely so they cannot inherit the policy disposition below.
+  refused by encryption policy, and all four identity bindings (sender identity,
+  session slot, leaf address, unsupported sender), which are intercepted
+  *before* classification precisely so they cannot inherit the policy
+  disposition below. The session slot binding runs before any AEAD, since every
+  failure the MLS library raises below it happens before it authenticates
+  anything; the credential comparisons run once decryption has succeeded.
   Acknowledging would confirm to an attacker that this device is online and
   processing, and unmarking is what stops an exact replay from reaching the
   duplicate re-acknowledgement path and leaking the same fact anyway.
-- A frame refused on **policy** grounds keeps its acknowledgement. A membership
-  commit refused by opt-in enforcement is the case in point: the refusal is
-  permanent, so a resend could only waste work.
+- A frame refused on **policy** grounds keeps its acknowledgement **when the
+  refusal happens on the arrival path**. A membership commit refused by opt-in
+  enforcement is the case in point: the refusal is permanent, so a resend could
+  only waste work. A frame already deferred into the group buffer that later
+  resolves as a policy refusal is never acknowledged, because the arrival path
+  withheld the acknowledgement already.
 - A frame that failed for a **recoverable** reason gets no acknowledgement, so
   the sender's resend is the recovery path.
 
@@ -194,8 +200,13 @@ answers corrupt the members cache, which is **not** the MLS roster and is never
 read by roster-derived logic, but is read verbatim as the group fan-out send
 cache: an accepted forgery therefore makes this device address every subsequent
 group ciphertext to an attacker-chosen identifier, or stop addressing a real
-member. Adds are gated on internet arrival and removes on an administrator
-check, which is what bounds this.
+member. The same list feeds the sealed rich payload gate, which requires every
+non-self member to be known rich-capable, so an unknown spliced identifier
+closes it: reply context and forward attribution move from inside the MLS AEAD
+to hop-visible cleartext and media secrets are dropped, until the next commit
+refreshes the cache. That defeats a control this document lists by name, reached
+by the adversary that control names. Adds are gated on internet arrival and
+removes on an administrator check, which is what bounds all of this.
 
 **Why it stands:** these frames have no signer. Closing it means moving relay
 answers onto dedicated entry points.
@@ -315,7 +326,7 @@ is the one application-supplied payload that boundary 5 does **not** cover, so
 
 **Why it stands:** discovery is a broadcast to peers with whom no session
 necessarily exists, so there is no established group to encrypt to; encrypting
-request and response bodies is designed but not implemented.
+request and response bodies is not implemented.
 
 **What application teams must do today:** treat a service body as public, and
 encrypt anything sensitive above the SDK before handing it over.

docs/spec/control-messages.md

@@ -114,11 +114,13 @@ two mandatory properties, and both are load-bearing:
 2. They MUST be pinned to the internet transport rather than routed by the
    transport selector. The selector demotes the internet transport by design,
    and some mesh transports swallow a self-addressed frame: Wi-Fi Direct and
-   Reticulum enqueue it unconditionally and report success (Bluetooth LE fails
-   closed instead, because self is never a connected peer). The caller then
-   believes the broadcast succeeded and skips its per-member fallback,
-   delivering to nobody. One such transport is enough to lose the frame, which
-   is why the rule is a pin rather than a preference.
+   Reticulum enqueue it unconditionally and report success. Bluetooth LE fails
+   closed, because self is never a connected peer, but that only helps on a
+   BLE-only device: a synchronous refusal is a fallback trigger, so the frame
+   reaches one of the others anyway. The caller then believes the broadcast
+   succeeded and skips its per-member fallback, delivering to nobody. One such
+   transport is enough to lose the frame, which is why the rule is a pin rather
+   than a preference.
 
 Retry policy for these frames lives at the application layer instead, with
 explicit trackers and bounded attempts.

docs/spec/group-protocol.md

@@ -202,13 +202,21 @@ Roster change events carry a three-valued authorization field:
 An implementation MUST NOT emit "authorized" from a path that ran no check. The
 third state exists precisely so that path has something honest to say.
 
-Relay-reconciled **removes** are the asymmetry in that last row, and they are
-not "not evaluated": the remove path MUST check the authenticated wire sender
-against the administrative set and drop the frame when the sender is not an
-administrator, then report a real verdict. Adds cannot do this, because the
-frame authenticates the *path* rather than the actor, so `added_by` may be the
-relay itself. Omitting the remove-side check lets any peer evict members from
-the fan-out send cache and silently deny them group traffic.
+**Removes** are the asymmetry in that last row. The remove handler MUST check
+the authenticated wire sender against the administrative set, drop the frame
+when that sender is not an administrator, and only then report a real verdict.
+Adds cannot do this, because the frame authenticates the *path* rather than the
+actor, so `added_by` may be the relay itself. Omitting the remove-side check
+lets any peer evict members from the fan-out send cache and silently deny them
+group traffic.
+
+Note what that check implies for genuinely relay-originated removes: the relay's
+answer is injected unattributed, so its sender is a placeholder that can never
+be an administrator and the frame is always dropped. **Relay-native remove
+reconciliation is therefore inert**, and the path that actually removes a member
+is the removing administrator's own signed notification. This is a consequence
+of the rule, not a gap in it: restoring relay-native reconciliation means moving
+relay answers onto a dedicated entry point rather than weakening the check.
 
 ### The delta is derived only when both roster reads succeed
 

docs/state-machines/transport-lifecycle.md

@@ -178,4 +178,6 @@ This is a recurring source of confusion for application teams:
 Only the last one is delivery. Unconditional-enqueue transports are the reason
 relay hint frames must be pinned rather than routed: such a transport swallows a
 self-addressed frame and reports success. Wi-Fi Direct and Reticulum behave this
-way; Bluetooth LE fails closed, because self is never a connected peer.
+way. Bluetooth LE fails closed, because self is never a connected peer, but that
+only helps on a BLE-only device: the transport manager treats a synchronous
+refusal as a fallback trigger and hands the frame to one of the others anyway.