docs: record phase 10, and the deferred decision it carries out

`docs/subgroups.md` was written as ten phases of reasoning kept in the order they
were argued, and phase 4 spent forty lines on why the child's ceremony was *not*
held in the parent's Marmot room -- explicitly so the decision would not be
re-litigated without its price attached. That section is now a shopping list that
has been carried out, so it keeps its argument and gains a pointer forward, and
the three costs it enumerated are checked off one by one in a new phase 10.

The parts of the note that state the old arrangement as present-tense fact are
updated rather than annotated: the three-ceremonies table now reads one room,
three ceremonies, two quorums, and says the thing that needs saying twice -- an
MLS message reaches the whole tree, so a ceremony in the parent's room has to name
who it is with.

Phase 10 itself is written the way the others are, around what fails silently:

- `DkgSession.chatRoomId` stopped identifying a ceremony, and the place that
  matters is `completedKey`'s last fallback, which every member welcomed after a
  group's own ceremony lands on;
- `signingPath` had to admit a Marmot room, which widens the one function whose
  contract is that a path never comes off a proposal;
- the p-tags had to stay on both transports, which is the opposite of what
  `FrostSigningManager` correctly does.

The two sections that argued the old collision -- "The collision this buys" and
"Why a subgroup cannot be the whole group was withdrawn" -- keep their reasoning
and gain the end of it: `(room, parent)` stopped telling two subgroups of one
parent apart, so the lookup moved to `(room, parent, admins)`, and the permanent
half of the refusal disappeared with the derived room. The limitation and the
appendix entry are struck through rather than deleted, since what they were
weighing is why the phase exists.

`docs/shared-key-ceremony.md` no longer says a ceremony runs over a NIP-17 chat.
The participant set is the proposal's p-tags on both transports, and that
distinction is the whole reason it is stated that way rather than as "the group".

`docs/mls-skipped-keys.md` keeps `proposeRitual` in its table of reliable
triggers and now says what changed about it: it reached that table on gift wraps,
where the bug does not apply, and a subgroup's ceremony now rides group events. It
is the entry with the worst consequence -- a ChillDKG cannot finish until every
participant takes part, so one lost round-1 message stalls it permanently for
everybody rather than costing one member a line of chat. That is the thing the
quartz fix in that note is now load-bearing for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/shared-key-ceremony.md

@@ -1,15 +1,21 @@
 # The shared key ceremony
 
-A group creates a `t`-of-`n` FROST key by running ChillDKG over its NIP-17 chat.
-No trusted dealer, no single device ever holding the whole key.
+A group creates a `t`-of-`n` FROST key by running ChillDKG over its own chat. No
+trusted dealer, no single device ever holding the whole key.
 
 Implemented in `ChillDkgRitualManager`, on `fr.acinq.bitcoin.crypto.dkg.chill.ChillDKG`.
 
 ## Shape
 
-The group is the participant set, the member who opens the ceremony coordinates
-it, and every protocol message travels as a gift-wrapped rumor on the same NIP-17
-pipeline chat messages already use — so there is no second transport to operate.
+The participant set is who the proposal `p`-tags, the member who opens the
+ceremony coordinates it, and every protocol message travels on a pipeline chat
+messages already use — a gift-wrapped rumor in a NIP-17 room, an MLS application
+message in a Marmot one — so there is no second transport to operate.
+
+A group's own ceremony runs in the NIP-17 room its members share, and there the
+participant set and the room's membership are the same thing. A **subgroup's**
+runs in its parent's Marmot room over a subset of it, which is why the set is the
+p-tags rather than the room: see [subgroups.md](./subgroups.md).
 
 The coordinator is a participant too, and ChillDKG treats it as untrusted: it
 relays and aggregates but cannot learn secrets or bias the key. Being the room's