keep-frost-net: wire opt-in strict relay cert pinning to eliminate first-use TOFU

[kwsantiago]

Problem

Relay certificate pinning trusts the certificate on first use: when no pin exists for a host, verify_relay_certificate (keep-frost-net/src/cert_pin.rs) records the observed certificate as the pin. An attacker who intercepts the very first connection to a relay pins their own certificate, and all subsequent connections then validate against the attacker's key.

Status

The mechanism to close this is in place: verify_relay_certificate takes a require_pinned policy parameter; when true, an un-pre-provisioned host is rejected instead of trusted-on-first-use. It is a per-call policy (not persisted state) so it cannot fail-open on a pin-set reload.

Not yet activated: both live call sites (keep-desktop, keep-mobile) pass require_pinned = false, so default TOFU exposure remains.

Remaining work

1. Add a config/CLI toggle (mirroring the opt-in --expected-pcr strict attestation) to pass require_pinned = true.
2. Document provisioning relay SPKI pins out-of-band (the pins JSON) for high-assurance deployments.
3. Optionally, surface a first-use pin-confirmation prompt (fingerprint) in keep-desktop / keep-android for the non-strict path.

Acceptance criteria

• A deployment can enable strict pinning so an unknown relay is rejected rather than TOFU-trusted.

[kwsantiago]

Closed by #826: desktop now has the opt-in strict-pinning toggle (mobile already shipped it in #812), so a deployment can enable strict pinning to reject un-pinned relays instead of TOFU-trusting them (items 1-2). Out-of-band SPKI pin provisioning is documented in docs/SECURITY.md. Item 3 (optional first-use fingerprint-confirmation prompt) is a separate UX enhancement, not required for the acceptance criteria. Note: the pin is currently enforced on a pre-flight probe, not the live data connection; that gap is tracked separately.