docs: stop the adoption note naming a schema version, since two landed under it

Seventy-one commits of `mantra` merged in -- npub and nsec sign-in, several profiles
on one device, three pulls from the Curated fork, a profile preview and a FAB sweep --
and none of it touches subgroups. `docs/subgroups.md`, `SubgroupManager`,
`GroupKeyStateManager`, `GroupKeyStateEvent`, `nostr/subgroup/`, `GroupKeyState` and
`ProposedEvent` are byte-identical, so the design stands as written. The only
`FrostSigningManager` change is a comment, recording that putting a signed event on
relays is now a member's separate act from `BroadcastGroupSignedEventScreen`.

**The note said schema 19 -> 20, and 20 was taken while it sat there.** 19 was Phase
10's, for `DkgSession.participantPublicKeys` and `subject`; 20 is the several-profiles
pull's, putting an owning identity on the queues. This is the second time the number
has moved under a note that is not being built yet -- it was 18 -> 19 when first
written three weeks ago -- which is twice too often for a figure nothing depends on.
So it now says to read the version off `MantraDatabase` at build time, and the test
line that named one does not.

Everything else re-checked against the merged tree and unchanged: the four
parent-indexed DAO reads are still test-only, `ChatRoom.parentChatRoomId` still has no
production reader, `describe(purpose, path)` still takes no parent, and
`GroupSignedEvent` still declares its foreign key onto `ChatRoom` -- the last of which
is load-bearing for this design, since it is what forbids a child device storing a
certificate signed by a group it is not in, and so forces the certificate to ride
inside the key state.

`docs/README.md` merged without a conflict: the row for this note sits where it was
put, under the subgroups row, and the seven rows the sign-in and pull notes added
append below it.

Merged through the app's host sync rather than `git merge`, because the merge brings in
a `.gitmodules` line -- `branch = master` on the lightning-kmp-app submodule -- which
the sandbox is not meant to write.

Docs only -- no code changed by this commit, so there are no test counts to report.
The merged changes have not been built here.

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

docs/subgroups-multiple-parents.md

@@ -256,10 +256,12 @@ adoption is glad not to be entangled with.
 [found while reading](#found-while-reading)), and leaving it holding one of
 several parents makes it a cache that is wrong rather than merely unused.
 
-Schema **19 → 20** — 19 is Phase 10's, for `DkgSession.participantPublicKeys` and
-`subject`: one new table, one dropped column, and the existing rows carried across as
-a single parentage row each. Not an `AutoMigration`; schema
-9→10 already has the shape to copy.
+Schema **20 → 21**, and the number moves under this note faster than the design does:
+19 was Phase 10's, for `DkgSession.participantPublicKeys` and `subject`, and 20 was the
+several-profiles pull's, putting an owning identity on the queues. So take the version
+from `MantraDatabase` when this is built rather than from here. One new table, one
+dropped column, and the existing rows carried across as a single parentage row each.
+Not an `AutoMigration`; schema 9→10 already has the shape to copy.
 
 ### The zero-migration alternative, and why not
 
@@ -548,7 +550,7 @@ otherwise.
   key, a real P1 key and state, a real P2 key, a real certificate by P2 over the
   child, a real **re-announced** state carrying both, and the assertion that
   `stateFrom` accepts it and rejects each single-field mutation.
-- `SubgroupDaoJvmTest` — schema 20 round-trips the table, a newer state replaces
+- `SubgroupDaoJvmTest` — the new schema round-trips the table, a newer state replaces
   the parentage rows of an older one, and a re-announcement that drops a parent
   leaves no row behind.
 - `SubgroupManagerJvmTest` — the two guard tables, and the candidate filter: a room