docs: log Aug 17 Sentinel check-in, file per-language checksums idea

TLS fingerprint fix (v0.3.7) checked in 17 days post-release: aggregate
CLI Sentinel-rejection rate still ~21%, unchanged -- inconclusive given
mixed-version population, revisit once 0.3.7+ dominates usage.

New backlog item: per-language SHA256 checksums on product pages.
Confirmed live that Microsoft's own download pages publish a static
per-locale hash table for the current build, not reachable through any
API call MSDL/CLI already makes. Since it only changes when a product
ID is replaced, no scraper needed -- just copy it by hand at the same
time a new product gets added to the catalog.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

CLAUDE.md

@@ -61,16 +61,33 @@ signal, since Go's stdlib `crypto/tls` doesn't look like any real browser, indep
 - [x] **Validate `product_id` in `/proxy`** — was passing unknown IDs straight through to a
       real Microsoft session attempt (found via a stray `product_id=2861`, never a real
       product, in the logs). Now rejected with 404 before any outbound call. (same PR, merged)
-- [ ] **CLI TLS/HTTP2 fingerprint hardening** — swapped the CLI's transport from stdlib
+- [x] **CLI TLS/HTTP2 fingerprint hardening** — swapped the CLI's transport from stdlib
       `net/http` to `github.com/bogdanfinn/tls-client` (wraps `utls` with a maintained Chrome
-      profile). Verified functionally correct (real link fetched + contributed end-to-end),
-      but does NOT yet prove the fingerprint theory — the old client already succeeded ~80%
-      of the time. Need to watch the Sentinel-rejection-rate telemetry over a comparable
-      multi-day window post-merge. (feat/cli-tls-fingerprint-hardening, not yet merged)
+      profile). Shipped in `cli/v0.3.7` (merged, released 2026-07-31). **Checked in on
+      2026-08-17, 17 days post-release: inconclusive-to-negative.** Aggregate CLI
+      Sentinel-rejection rate is still ~21%, statistically unchanged from every pre-fix
+      checkpoint. Real caveat: mixed-version population (`0.3.6`: 1156 actions vs `0.3.7`: 493
+      in that window) means a `0.3.7`-only improvement could still be masked — `/metrics`
+      doesn't break the error down by CLI version, so this can't be fully isolated yet. Revisit
+      once `0.3.7`+ dominates usage share; if the aggregate still hasn't moved by then, treat
+      the fingerprint theory as disproven.
 - [ ] **`/needs-warming` community page** — proposed, not built. Surfaces products currently
       failing web users (active Sentinel/rate-limit lockdown, no cached/stale link available)
       with a one-click CLI command to fix it. See
       `docs/superpowers/specs/2026-07-13-needs-warming-design.md`.
+- [ ] **Per-language SHA256 checksums on product pages** — Microsoft's own download pages
+      (e.g. `/software-download/windows11`) publish a static hash table (one SHA256 per
+      locale) for the *current* ISO build, confirmed live via direct network inspection
+      2026-08-18. It's not in any API response MSDL/CLI call (`GetProductDownloadLinksBySku`
+      never includes a hash, confirmed against Microsoft's own live page too) — it's static
+      HTML on the Windows-version download page, tied to the product/build, not the session.
+      Since it only changes when a product ID is replaced (same trigger as adding a new
+      catalog entry), no scraper/refresh job needed: copy the hash table by hand at the same
+      time a new product ID is added, per the existing "Adding a new consumer Windows release"
+      steps in CONTRIBUTING.md. Open questions before building: where to store it
+      (`products.json` field vs. separate file), which languages to cover (all 38 vs. just
+      the popular ones), and where to surface it (collapsible "Verify your download" section
+      on the product page, mirroring Microsoft's own UX; maybe CLI output too).
 
 ### Known bugs / open issues