Make identity something you can look at and change

`id` now shows what this device is — the key it signs with, the name it
answers to, the secret of every network it has joined — and changes all
of it. One shape throughout: name a thing to see it, name it with a value
to change it. `secret` folded in as `id secret generate`, and the path
flags became global so they work either side of a subcommand.

There is no separate signing certificate to show: the endpoint key is
what signs records, and the report says so rather than leaving it to be
guessed.

Secrets appear in `id`, which is where you go to ask for one, and stay
out of `status`, logs, `Debug` and anything sent to a peer.

The hostname is now a signed claim, which is what makes changing it a
revocation. Records are one per author, so a new version replaces the
whole claim and no replica can keep the old name standing. RecordBody
generalised to Claim { address, range, hostname } + Release for that,
with the signing domain bumped; a name is bounded and canonicalised, and
a non-canonical one is rejected rather than repaired, because a repaired
version is not what its author signed. Two members claiming one name
resolve it like an address: lowest id wins, computed identically
everywhere. A member with only a name now has a record too, so an
IPv6-only network finally has a durable roster and an absent member can
be named rather than shown as a bare id.

Replacing the signing key is allowed and does not break the store. The
outgoing key signs a release for every network first, so the address and
name it held are freed rather than reserved forever to a key nobody has
— nothing can sign for a retired author, and by design no authority
could overrule one. Identity and releases commit together: a crash
between them would leave the old key gone and unable to sign what it
owed. It refuses while an agent holds the directory, rather than failing
on the lock with a message that says nothing about what to do.

The version counter is keyed by author as well as network, so a
replacement key starts its own sequence. The migration drops records
written under the previous signing domain instead of carrying rows that
every read must reject and that look exactly like corruption.

The hostname defaults to the machine's own name. Also fixed a
pre-existing flaky test: 40 random authors in a /24 collide by the
birthday problem often enough that its threshold failed about one run in
six, so the authors are fixed now and it tests a property rather than a
coin flip.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -70,7 +70,7 @@ On the first machine:
 
 ```bash
 cargo build --release
-./target/release/tsunagi secret          # prints tsn1...; share it privately
+./target/release/tsunagi id secret generate   # prints tsn1...; share it privately
 ./target/release/tsunagi status          # this device, the agent, and this host
 
 ./target/release/tsunagi up --network lab --secret "$SECRET" --wireguard
@@ -184,6 +184,36 @@ sayable — it remembers who belongs while they are gone, so the report can say
 dial-failure counter to imply it. Counters are history and are never graded:
 a peer that left and came back should not leave the report looking broken.
 
+`id` is the other half: it shows what this device is — its signing key, the
+name it answers to, and the secret of every network it has joined — and
+changes those. Every item takes the same shape, so there is nothing to
+remember: name it to see it, name it with a value to change it.
+
+```
+tsunagi id                      everything about this device
+tsunagi id hostname             the name it answers to
+tsunagi id hostname mango       change it
+tsunagi id key                  the key it signs with
+tsunagi id key rotate           replace that key
+tsunagi id secret               the secret of each joined network
+tsunagi id secret generate      a fresh secret for a network that does not exist yet
+```
+
+Secrets appear in `id`, which is where you go to ask for one, and never in
+`status`, in a log, in a `Debug` rendering or in anything sent to a peer.
+
+The name is part of the signed state, so changing it revokes the previous
+one: there is one record per author, a new version replaces the whole claim,
+and no replica can keep the old name standing. Changing it while the agent
+runs goes through the agent, which republishes and tells its peers straight
+away.
+
+Replacing the signing key makes this device a different member, and it loses
+the address and name the old key held — nothing can sign on a retired key's
+behalf, and by design there is no authority that could overrule an author. So
+the outgoing key signs a release for every network on its way out, which
+frees them for whoever wants them next, and the whole thing commits at once.
+
 `status` and `id` both prefer a running agent, which is live and
 authoritative, and fall back to reading the state store when there is none.
 Reading takes no directory lock, so neither has to wait for the agent it is