v0.6.0 — verified Akamai HTTP/2 fingerprint parity

HTTP/2 (Akamai) fingerprint: verified, byte-level

The frame-level HTTP/2 client (introduced in v0.2.0) drives the connection over uTLS with http2.Framer + hpack, emitting the browser's SETTINGS, connection WINDOW_UPDATE and pseudo-header order instead of Go's net/http2 defaults. This release makes that parity verifiable and honest.

Added

• Byte-level unit tests (http2_wire_test.go) — assert the exact preface + SETTINGS + WINDOW_UPDATE bytes the client writes (an independent hand-rolled byte reference plus a fully literal Chrome expectation), and that HEADERS carries each profile's four pseudo-headers in order followed by the regular headers in HeaderOrder. No network needed.
• cmd/measure is now reflector-configurable — -url flag / REFLECTOR_URL env; tolerates reflectors that expose the Akamai string at the top level. Added chrome_android.

Verified (real measurements)

Measured against two independent reflectors — tls.peet.ws and fp.shshbshsnang.shop — which agree per profile:

Profile	Emitted Akamai h2	Match
chrome / edge / chrome_android	1:65536;2:0;4:6291456;6:262144|15663105|0|m,a,s,p	✅ byte-exact (canonical Chromium)
firefox	1:65536;4:131072;5:16384|12517377|0|m,p,a,s	✅ byte-exact
safari	3:100;4:4194304|10420225|0|m,s,p,a	✅ values & pseudo-order; see caveat
ios	3:100;4:2097152|10420225|0|m,s,p,a	✅ values & pseudo-order; see caveat

Honest caveat: Safari/iOS SETTINGS values and pseudo-order are correct for WebKit, but public fingerprint DBs disagree on SETTINGS ordering and the exact WINDOW_UPDATE increment, and these were not cross-checked against a real device. See the README parity table.

CI green (build / vet / gofmt / test on Go 1.25).