Decide and implement certificate validation, including the self-signed server

[iderex]

A large share of self-hosted servers sit behind a certificate the operator issued
themselves. Refusing them outright excludes those operators. Accepting anything
turns every client into an open door on a hostile network, and it is exactly the
kind of default that gets copied into eleven clients because the core made it
easy.

This is a security decision that has to be taken deliberately and written down
before any client depends on the behaviour.

What this produces

Validation on by default, with no way to turn it off through configuration the
core reads on its own.

If an exception mechanism exists at all, it is per server, it is initiated by the
operator through the client, it stores what was trusted rather than a blanket
permission, and it is visible afterwards. The core exposes the certificate that
failed so the client can show it. The core never decides to trust anything.

A named error in the vocabulary from #4 that distinguishes a validation failure
from any other transport failure, since the two need different sentences.

Done when

The decision is recorded in docs/decisions/. A test proves the core refuses an
untrusted certificate by default against the fake server. A test proves the
exception path, if there is one, is scoped to one server and does not widen to a
second. Blocked on #4, #21 and #101.

[iderex]

The decision landed as docs/decisions/0029-certificate-validation-and-the-self-signed-server.md, on cf9705d.

Validation is always on and there is no configuration the core reads on its own that weakens it: not a field on a call, not an environment variable, not a build flag, not a debug mode. There is nothing for a client to set, for a tutorial to copy, or for a person to be talked into.

The exception exists and it is a pin on one exact certificate. It is identified by a fingerprint over the whole encoding rather than over the public key, because what a server prints and what a person can read off their own machine is a certificate fingerprint, and a pin an operator cannot check by comparing two strings is one they will accept without checking. It reaches one server and no other. It is offered only by the client, only after a refusal, and only with the presented chain, the fingerprint, the reason class and the validity window in hand, since 0003 leaves the core no words to ask with.

The part that decides whether the exception is safe is what a pin never becomes. A pinned certificate is not a trust anchor. A certificate signed by it is refused, and a chain that merely contains it is refused. Installing the operator's certificate as an anchor is the shape that reads as the careful answer and authorises that key to answer for any name at all, including ones the person never typed.

What a pin does replace is the chain, the name and the validity window, and the record says why each of the three was overridden by the operator's assertion rather than dropped. It also says what that leaves standing: a pinned certificate whose key was taken stays acceptable until the operator removes the pin, and there is no revocation route for one. That is an accepted residual and it is the record's first reversal condition rather than something left unsaid.

Two things this issue did not ask for and the record settles because they would otherwise be settled by accident. The six reason classes, since 0004 fixed that certificate-rejected carries a reason class and never said what the classes are, and a class nobody wrote down becomes a string a client switches on. And that nothing is sent over a connection whose certificate was not accepted, which is the difference between a refusal and a credential already delivered.

Where the pin lives is decided here as well, because it is the question that decides whether the exception survives a restart. A certificate is public, so a pin is not a secret and goes to the byte store in #40 rather than the secret store in #33, keyed by the server and the device and not by the account. The cost of dropping the account from that key is stated in the record rather than hidden: a second account on a shared device inherits a decision the first account's operator took.

Both test conditions here are untouched. Proving the core refuses an untrusted certificate by default, and proving the exception path does not widen to a second server, are statements about running code against a server that can be made to present a certificate the core will refuse. There is no language chosen, no build and no test command in this tree, and #21 is open. This stays open on both.