Add Chrome 150 TLS profiles

[icew4y]

Summary

• Add HelloChrome_150 and HelloChrome_150_PSK profiles.
• Add ML-DSA signature scheme constants/string mappings for 0x0904, 0x0905, and 0x0906.
• Keep HelloChrome_Auto on Chrome 133 until upstream Go TLS support for ML-DSA certificate signatures is available in uTLS.
• Keep trust_anchors out of the Chrome 150 profiles.

Rationale

Chrome 150 advertises ML-DSA signature schemes, but the current uTLS handshake implementation is based on a Go TLS stack that cannot verify or produce ML-DSA CertificateVerify signatures yet. The explicit Chrome 150 profiles are still useful for fingerprint parity, while HelloChrome_Auto should avoid advertising capabilities that the stack cannot complete. Go 1.27 draft release notes include crypto/mldsa, crypto/x509 ML-DSA support, and crypto/tls ML-DSA TLS 1.3 support, so Auto can move after that upstream support is available here.

Sources

• Chromium M150 source keeps kTLSTrustAnchorIDs disabled by default and enables kTlsMldsaSignatures: https://github.com/chromium/chromium/blob/150.0.7871.47/net/base/features.cc#L625-L627
• Chromium commit enabling ML-DSA signatures by default: chromium/chromium@c70ed37
• Go 1.27 draft release notes include ML-DSA support in crypto/mldsa, crypto/x509, and crypto/tls: https://go.dev/doc/go1.27#crypto_mldsa
• Chrome 150 stable announcement, June 30 2026: https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_0175352312.html
• Chromium Dash M150 schedule: https://chromiumdash.appspot.com/schedule

Tests

• go test -run 'TestHelloChrome150|TestHelloChromeAuto'
• go test -count=1 ./...

[4erdenko]

Am I reading the current implementation correctly?

The PR description says HelloChrome_Auto should remain on Chrome 133
until native Go ML-DSA support is available. However, the default
mldsa_circl.go implementation returns goMLDSASupported() == true, so
defaultChromeAutoID() selects HelloChrome_150 in normal builds.

Is the intention now to treat CIRCL support as sufficient for Auto,
despite pure ML-DSA certificate chains still not being verifiable by
crypto/x509?

It may be safer to:

1. merge HelloChrome_150 as an explicit profile;
2. keep HelloChrome_Auto on 133 for now;
3. switch Auto separately after native Go/x509 support is integrated.