doc: add design for mutual TLS client authentication

Proposes mutual TLS as an admission gate for external SQL connections, as an
alternative to IP-based network policies. Egress IPs are unstable behind NAT
gateways and cloud NAT pools, an IP is not an identity, and an allowlist has no
rotation or revocation story.

The obstacle specific to Materialize is balancerd, which terminates TLS and
opens a separate pgwire connection to environmentd, so the process that sees the
client certificate has no tenant configuration and the process with the
configuration never sees the certificate.

The design separates proof of possession from trust evaluation. The handshake
proves the client holds the leaf's private key and only the terminating proxy
can obtain that proof, but judging the issuer is a pure function of a chain and
a set of trust anchors. balancerd therefore forwards the chain and environmentd
judges it, so balancerd never learns any tenant's certificate authority and
stays stateless. environmentd honours a forwarded chain only from a peer that
authenticates against a configured proxy authority.

Also records a three phase roadmap: system parameters with environmentd
enforcing, then edge filtering at balancerd over a cacheable API, then
CREATE CERTIFICATE AUTHORITY for per-authority scoping. Alternatives cover the
catalog object syntax, edge filtering, TLS passthrough, and folding certificates
into network policies.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: jubrad