docs: say why the two hash tags and the relay host must never be renamed

Phase 0 of docs/curated-to-mantra.md, item 3. Three strings in this tree spell
"mantra" for reasons that have nothing to do with the brand, and until now
nothing beside them said so: `SharedKeyDerivation.TWEAK_TAG` and
`ChillDkgRitualManager.HOST_KEY_DERIVATION_TAG` are inputs to hashes, and
`Relays.ephemeral` is a relay that is running. Each now carries a comment
saying what renaming it would cost, and docs/shared-key-derivation.md gets the
paragraph that ties the three together.

**The comments come from the fork, and are rewritten rather than pulled.** The
Curated fork found out what these strings were the hard way: it renamed the app
twice, and each time had to decide which of thousands of "mantra" tokens were
the brand. Its rebrand commits (3bc8be53, e6aee792) left these three alone and
wrote down why, and run through the pull's name-rewrite those commits collapse
to almost nothing but those comments. They were not taken as commits, because
what survives the rewrite is a sentence like "has survived two rebrands --
Mantra to Curated, Curated to Mantra", which in this repository describes
rebrands that never happened. The fact they state from this side is different
and worth stating plainly: the fork keeps all three byte for byte, so a Mantra
member and a Curated member of one group derive one key and talk to one relay,
and a rename *here* would split them as surely as a rename there.

**Why comments at all, when the derivation note already has the rule.** The
note's one rule is about the path a key is derived along; it never said that
the tag string itself is part of the derivation, and the failure mode of
renaming it is silent -- every room orphaned, every partial signature
aggregating to nothing that verifies, and nothing on screen to say so. A
`v2` tag is the shape a deliberate change would take, and the comments say so,
so that the next person to grep for the brand finds the answer before the
diff.

**`ComposeAppCommonTest` moves from `press.auxiliary` to `press.mantra`.** It
is the KMP template's `1 + 2 == 3`, the last file under a package the app
vacated two brands ago, and the fork relocated it rather than deleting it so
the source tree has one root package instead of an orphan under an empty one.
Same here; it is moved with `git mv` so its history follows.

No behaviour changes. :composeApp:jvmTest 736 tests, 0 failures;
:composeApp:testDebugUnitTest 403 tests, 0 failures; :composeApp:m3Audit all
budgets met.

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

docs/shared-key-derivation.md

@@ -65,6 +65,16 @@ Each scalar commits to the key being tweaked as well as the index, so steps cann
 be reordered or replayed at a different depth to reach the same key.
 `listOf(0L)` and `listOf(0L, 0L, 0L)` do not collide — there is a test for it.
 
+The `mantra/` prefix is deliberate and is not a brand string: the string is an input to
+the hash, so renaming it derives different keys from the same threshold key — orphaning
+every room already created, and splitting devices on the new string off from devices on
+the old one, since their partial signatures would no longer aggregate to one that
+verifies. The Curated fork of this app keeps it byte for byte for that reason, and so
+must this one. A rename is a protocol fork and would need a `v2` tag, not an edit to
+this one. The ChillDKG host-key tag in `ChillDkgRitualManager` is protected by the same
+argument, and `Relays.ephemeral` stays on its `mantra.press` host for the duller reason
+that it is a relay that is running.
+
 ### What avoiding BIP32 also avoids
 
 With x-only keys there is no single obvious `serP(K_par)`: BIP32 serialises