A token with all four parts

Given the broker's address and its certificate, mesh-control now issues a
token carrying everything ADR 0004 asks for: where to connect, what to expect
there, whose signature to believe afterwards, and a one-time right to join.
Verified by decoding one and checking the fingerprint against `openssl x509 |
sha256sum` -- they match.

The fingerprint is derived from the certificate on disk and never configured.
A configured pin can drift from the certificate it describes, and a drifted pin
is worse than none: every node issued a token during the drift refuses to
connect, and the failure looks like an attack rather than a mistake.

Computed over DER, which is what a client sees on the wire. Hashing the PEM
text instead would mean the same certificate, re-wrapped with different line
endings, produced a different pin -- there is a test for exactly that, and one
for pointing this at tls.key by mistake, which would otherwise produce a
confident pin over the wrong file.

Having no broker stays a state rather than a failure: a control plane holds
records and a signing key without one. Having half a broker is refused, because
a token with an address and nothing to check it against invites a node to trust
whatever answers.

Fault injection caught the same weak test I wrote earlier in the day -- asking
whether something failed rather than why, so deleting the guard changed nothing
because it failed one line later anyway. Both are now asserted on the reason.

README.md

@@ -37,6 +37,7 @@ mesh-control node list                  the nodes this mesh knows about
 mesh-control token issue --node <name>  a one-time right to join, for an existing record
 mesh-control token issue --new <name>   create the record and issue for it
 mesh-control identity show              this control plane's signing key
+mesh-control broker show                where the broker is, and what to expect there
 mesh-control version                    what this binary is
 ```
 
@@ -65,9 +66,16 @@ travels in every token. A node believes a declaration because it carries a signa
 transitive, so a compromised broker could forge declarations, and since the host applies whatever
 the link delivers that is the whole machine.
 
-**Still missing: the broker's address and its certificate fingerprint.** Both are step 5 of the
-substrate bootstrap and neither exists. `token issue` prints the token **and names what is
-missing**, rather than producing something that looks complete and cannot be used.
+**All four parts are built.** Given `MESH_BROKER_ADDRESS` and `MESH_BROKER_CERTIFICATE`, a token
+carries everything ADR 0004 requires. Without them it carries two, and `token issue` prints it
+**and names what is missing** rather than producing something that looks complete and cannot be
+used.
+
+**The fingerprint is derived from the certificate, never configured.** A configured one can drift
+from the certificate it describes, and a drifted pin is worse than none: every node issued a token
+during the drift refuses to connect, and the failure looks like an attack. It is computed over the
+DER bytes — what a client actually sees on the wire — so the same certificate re-wrapped with
+different line endings still produces the same pin.
 
 ### Two contexts, and the rule between them is real