feat(emulate): Add Chrome 150, 151, 152

[Soju06]

Adds Chrome 150, 151 and 152 to the emulation profiles and to the weighted
version selector (newest first), following the shape of #99.

sec-ch-ua brand strings

The GREASE token and the brand ordering are version-seeded, so they cannot be
extrapolated from 149. Each value was derived from Chromium's
GenerateBrandVersionList and then confirmed against a real binary:

version	sec-ch-ua
149	"Google Chrome";v="149", "Chromium";v="149", "Not)A;Brand";v="24"
150	"Not;A=Brand";v="8", "Chromium";v="150", "Google Chrome";v="150"
151	"Not=A?Brand";v="99", "Google Chrome";v="151", "Chromium";v="151"
152	"Chromium";v="152", "Not?A_Brand";v="24", "Google Chrome";v="152"

Verification method: each browser was driven headless into a local HTTP/2
server and sec-ch-ua was read off the request. Captures came from
Chrome for Testing 150.0.7828.0, 151.0.7872.0 and 152.0.7923.0.

The same capture path reproduces the existing v149 string byte for byte
against installed Chrome 149.0.7827.155, which is what validates the method
rather than the derivation alone. Chrome for Testing is Chromium-branded, so
its output omits the Google Chrome entry while the GREASE and Chromium
entries match exactly.

HTTP/2

Unchanged across 149 to 152 (Akamai hash 52d84b11737d980aef856699f885ca86),
so the new profiles reuse v132::build_emulation like v148/v149.

TLS: known limitation, documented in the source

TLS does change across these versions and wreq 6.0's public options cannot
express the delta, so this PR does not claim TLS parity:

149  t13d1516h2_8daaf6152771_d8a2da3f94cd
150  t13d1517h2_8daaf6152771_cb7bf5808d99
151  t13d1518h2_8daaf6152771_4980c97edce0
152  same normalized JA4 as 151

Chrome 150 added the ML-DSA signature schemes 0x0904/0x0905/0x0906 and
the trust-anchor extension 0xca34
(BoringSSL,
trust anchors);
Chrome 151 added extension 0x12e0.

Header emulation is exact; the TLS delta is called out in a source comment so
consumers know which layer moved.

Tests

Adds hermetic header assertions for Chrome152 on Windows and macOS in
tests/client.rs, using the existing local-server helper.

• cargo clippy --all-targets --all-features — clean
• cargo build --all-features — clean
• New Chrome152 tests pass

Note on the existing suite: cargo test --all-features shows 34 failures in
tests/emulate_chrome.rs. These are pre-existing on this branch's base —
verified by stashing the change and re-running, which produces the identical
34 — and appear to require outbound network access.

Not included

No changes to other browser families, no dependency or feature changes, and no
reformatting of untouched code.

[Soju06]

Pushed a follow-up commit (f395d94) fixing a header-order bug in the profiles
this PR adds.

What was wrong

Chrome 150 moved accept-language from just after accept-encoding to just
after the sec-ch-ua block. The v150/v151/v152 blocks reused
header_initializer_with_zstd_priority, which emits the 149 order, so the new
profiles were byte-wrong on a header they exist to reproduce.

Measured over HTTP/2 against real binaries:

149   sec-ch-ua … upgrade-insecure-requests … accept-encoding accept-language priority
150+  sec-ch-ua … accept-language upgrade-insecure-requests … accept-encoding priority

Position 12/13 → 4/13. Locale-invariant: probing with no locale flags, with
--lang=en-US, and with --lang=ja-JP all put it at 4/13 on 150+.

The fix

Adds header_initializer_with_zstd_priority_v150 plus a zstd_only arm of
header_chrome_accept_encoding — the existing arm bundles the language header,
which 150+ no longer emits in that position.

Profiles up to 149 are untouched and keep the existing initializer. That
matters: the shared macro backs 60 Chrome profiles plus Opera, so changing it
in place would have made every pre-150 profile wrong in the opposite direction.

Verification

Built through the napi binding and captured on the wire, one hermetic HTTP/2
server per profile:

profile	accept-language position	vs real binary
chrome_152	4/13	matches
chrome_151	4/13	matches
chrome_150	4/13	matches
chrome_149	12/13	matches (no regression)
chrome_148	12/13	matches (no regression)
chrome_142	12/13	matches (no regression)

Full header sequence compared element-wise, not just the one position.

cargo clippy --all-targets --all-features clean; cargo test --test client
passes both cases including the new Chrome152 assertions.