HTTP/3 client does not authenticate server certificates

The HTTP/3/QUIC TLS 1.3 client completes the handshake but performs no server authentication. In `src/core/quic/tls/client.zig` `onServerFlight()` extracts the public key from the first certificate and verifies the `CertificateVerify` signature with that same key - there is no check that the certificate:

- chains to a trusted root / is signed by a trusted issuer,
- is within its validity period,
- has appropriate key usage / basic constraints,
- has a SAN (or CN) matching `server_name` (which today feeds SNI only).

As a result any active on-path attacker can present a self-signed certificate and complete the handshake as the target server, then read and modify HTTP/3 traffic. This is a MITM gap for the client over untrusted networks.

Found in a security review. The transport is documented as experimental, but the missing client authentication was not disclosed; a docs warning is going up as an interim measure (see the docs PR).

The real fix is a feature: accept a trust store / CA bundle (and optionally a verifier callback) in the client config, and perform X.509 chain validation + hostname (SAN) verification in `onServerFlight` before trusting the extracted key. Tracking that work here.

Start in src/core/quic/tls/client.zig, especially onServerFlight(), and trace how the client config and server_name are used during the handshake. Define how a trust store or CA bundle and optional verifier callback should be supplied, then ensure certificate-chain, validity, key-usage, basic-constraints, and hostname checks occur before trusting the extracted key.

Written by the indexing model from the issue text.