Post-Quantum Cryptography: Connect CA needs ML-DSA certificate support for mTLS

France's ANSSI will [stop certifying security products without post-quantum cryptography starting in 2027](https://gizmodo.com/the-quantum-threat-to-encryption-is-coming-france-just-set-a-2027-deadline-2000773650) - the first hard regulatory deadline of its kind globally. Additional mandates: US NSA CNSA 2.0 (2027), NIST IR 8547 (deprecation by 2030, disallowed by 2035), EU critical infrastructure (2030).

## Summary

Consul's Connect service mesh uses mTLS with classical RSA/ECDSA certificates issued by its built-in CA. These certificates are quantum-vulnerable (Shor's algorithm). Consul handles billions of inter-service requests - all protected by certificates that will be breakable by quantum computers.

Go 1.24+ already enables X25519MLKEM768 key exchange by default, so Consul's TLS *transport* may passively have PQC. But the *certificate signatures* (authentication layer) remain entirely classical.

## Proposed Changes

1. Add ML-DSA certificate signing to Consul's Connect CA
2. Support hybrid ML-DSA + ECDSA certificates for backward compatibility
3. Add `ca_config.key_type = "ml-dsa-65"` configuration option
4. Requires Go 1.27's `crypto/mldsa` ([Accepted](https://github.com/golang/go/issues/77626))

## Context

- [NIST FIPS 204 (ML-DSA)](https://csrc.nist.gov/pubs/fips/204/final)
- [Go crypto/mldsa proposal](https://github.com/golang/go/issues/77626)

Start by tracing Consul Connect's CA configuration and certificate issuance paths, then check how Go 1.27's crypto/mldsa API supports ML-DSA certificates. Review the compatibility implications of hybrid ML-DSA and ECDSA certificates and define how ca_config.key_type would be represented. Done means ML-DSA signing, the specified configuration option, and backward-compatible mTLS behavior are covered by tests.

Written by the indexing model from the issue text.