Authorize a TLS peer by certificate fingerprint, as RFC 5425 §5.1 requires

[DavidCozens]

RFC 5425 §5.1 (End-Entity Certificate Based Authorization):

Implementations MUST support specifying the authorized peers using certificate
fingerprints, as described in Section 4.2.1 and Section 4.2.2.

The library authorizes a peer by certification path validation plus name matching,
which is §5.2. It offers no way to authorize a peer by its certificate fingerprint,
so §5.1 is not met — there is no fingerprint anywhere in Core/ or Platform/.

docs/tls.md carries this as an obligation, and the compliance matrix records
RFC 5425 §5.1 as Not Met until it is delivered.

Scope

Both shipped TLS streams must support it — the OpenSSL stream and the Mbed TLS
stream. A platform that supplies a TLS stream and cannot authorize by fingerprint
does not meet the contract.

§4.2.2 defines the fingerprint form the configuration has to accept: an ASCII hash
label, a colon, then the hash of the DER-encoded certificate as colon-separated
uppercase hex pairs. It names SHA-1 as mandatory, which deserves a decision rather
than an assumption — RFC 5425 is from 2009 and RFC 9662 modernised its cipher
suites without revisiting this.

Acceptance criteria

• An integrator can authorize a peer by certificate fingerprint on both shipped TLS
  platforms.
• The fingerprint form accepted is stated on the configuration field.
• docs/tls.md and each platform page describe what the platform delivers.
• The RFC 5425 §5.1 row moves off Not Met.
• Driven by failing tests first, per the TDD contract.