feat(tls): mTLS + Register proof-of-possession for peer_id registration

[MichaelTaylor3d]

Summary

Closes a real gap: a Register could previously claim ANY peer_id with no proof the registrant held the matching identity key. The only existing protection (registry.rs's RegisterOutcome::Occupied) refuses a duplicate register against a live peer, but does nothing to stop a fresh, spoofed claim of an unused/offline peer's id.

• Adds an optional mTLS listener (src/tls.rs): configure RelayServerConfig::tls_cert_path/tls_key_path (CLI --tls-cert/--tls-key, env DIG_RELAY_TLS_CERT_PATH/DIG_RELAY_TLS_KEY_PATH) and the relay terminates TLS itself, requiring a client certificate on every connection.
• DIG peers are self-signed (no CA — peer_id = SHA-256(TLS SPKI DER)), so the verifier (AnyClientCertVerifier) accepts any well-formed leaf and relies on rustls/ring's handshake-signature check for the actual proof-of-possession — a client cannot complete the TLS handshake without holding the private key matching its certificate.
• After the handshake, register_peer requires the Register's claimed peer_id to equal the one derived from the certificate actually used for that connection. A mismatch is refused with a new Error{code:6, IDENTITY_MISMATCH} before the registry is touched at all (verified to run even before the capacity check). A connection presenting no client certificate never reaches the RelayMessage wire — mandatory client auth fails the handshake itself.
• Chose rustls over native-tls specifically because native-tls hides the client leaf certificate on Windows/macOS (see dig-gossip's inbound-listener docs) — rustls gives reliable cert capture on every OS.
• The default plain ws:// listener (mTLS not configured — the canonical relay.dig.net load-balancer-terminated deployment) is unchanged: the anti-hijack refusal remains its only protection, exactly as before.

No dig-gossip wire coordination needed. The proof-of-possession lives entirely at the TLS transport layer (the handshake itself is the "signature"), not in an extra Register field — the wire's pre-existing peer_id field is simply checked against the transport identity instead of trusted blindly. Error code 6 is a purely-additive value in the existing numeric taxonomy, not a shape change.

Verified

• src/tls.rs unit tests: PEM loading, peer_id derivation (matches SHA-256(SPKI DER), cross-checked independently), a full real handshake over an in-memory duplex proving the server derives exactly the client's own cert-derived id, and that a connection with no client cert fails the handshake.
• tests/mtls.rs: full end-to-end over real TCP sockets — own-cert-id accepted, spoofed-id rejected with IDENTITY_MISMATCH, no-cert connection never reaches the wire, /health stays plain HTTP regardless.
• src/server.rs: register_peer-level regression tests for the identity check, including that it runs before the capacity check.
• SPEC.md §3.2/§7/§8, DESIGN.md, and README.md updated in the same unit; registry.rs's doc comment updated (this repo's version of the "planned, coordinated" note is now "implemented, opt-in").

Version bump: MINOR (0.3.0 → 0.4.0) — a new backwards-compatible opt-in capability (feat:); default behavior is unchanged for every existing deployment.

Test plan

• cargo fmt --all --check
• cargo clippy --all-targets -- -D warnings
• cargo test --all (all suites green, including the new tests/mtls.rs)
• cargo build --release
• cargo llvm-cov --all --ignore-filename-regex 'win_service\.rs' --fail-under-lines 80 → 92.08% lines (tls.rs itself 89.90%)
• cargo deny check → advisories ok, bans ok, licenses ok, sources ok (added ISC to the license allowlist for ring/rustls-webpki/untrusted; swapped the now-unmaintained rustls-pemfile — RUSTSEC-2025-0134 — for rustls-pki-types' own PemObject trait, already a transitive dep)

Flagged follow-ups (out of scope for this PR)

• Enabling mTLS end-to-end for the canonical relay.dig.net deployment additionally requires the load balancer to pass TLS through rather than terminate it — an infra change in the superproject's private infra/dig-relay/, not this repo.
• docs.dig.net/docs/protocol/peer-network.md's :::note The relay link is authenticated differently callout (~line 164) states unconditionally "the node does not present one to the relay" — true by default, but no longer universal once an operator enables --tls-cert/--tls-key. Worth a follow-up docs.dig.net PR.

Refs DIG-Network/dig_ecosystem#5