tools(sentry): anchor the measurement windows on the gate's rollout instant

[dzianisv]

Stacked on #173 (which is stacked on #172). Review/merge in order.

The windows were free-form, so the reads scheduled for 08-17 and 08-21 could not be trusted

The gate reached Play production at 2026-08-14 14:22Z. A measurement window that spans that instant contains devices that could not possibly have run the gate. Its rate is neither a baseline nor a result — and it prints identically to both.

This is not hypothetical. I ran --window "post=2026-08-14T07:00:00Z..now" against this very script earlier today. 84% of that window predated the rollout, and it reported opencode-mobile rising to 4.44/h. Same tool, same data, wrong conclusion, no warning.

Worse: noise-gate-report.mjs — the script that produces the ticket's verdict — shipped with the identical defect as its default. post = now-7d..now straddles the rollout on every run before 08-21, which dilutes the after-rate toward baseline. The bias runs one way: it grades the gate as less effective than it is, on exactly the dates the ticket schedules its reads.

What changed

• --since-rollout reads the rollout instant out of the release-history table in docs/playstore.md — the same table the publish workflow already makes humans update — and splits the windows exactly there. It takes the earliest production release with versionCode >= 150, so a later v0.4.15 does not silently restart the measurement window.
• Every window prints its phase: [pre], [post], or [mixed] with the percentage that predates the gate. A young post window prints how many hours of uptake it actually has.
• An unparseable or missing release table reports unknown, never a silent post. Absence of the record must not read as a clean measurement.
• noise-gate-report.mjs returns UNGRADED for a mixed or unknown post window, consistent with how it already treats before_send == 0 and zero Play share.
• Its baseline default is pinned to the documented post-box-bot-fix window. A 7d lookback spans the AGE-55 fix and dragged ~22k/mo of already-dead openclaw-box-bot volume into the org estimate: the report said "MISSES the org gate by 18,612/mo". With the correct baseline it reads 628/mo, clears. Both from live data, minutes apart.
• before_send == 0 is now reported as expected in a pre/mixed/young window, and as a failure only after 24h+ of gated production. Previously it always printed as "no device is running the gate", which at 1.4h post-rollout is alarm noise.

Server-side levers re-probed, and the record corrected

Re-ran every lever with a write-scoped token, so none of these answers is a permissions artifact. Two of the three previously recorded conclusions were wrong in ways that would misdirect the next person:

Lever	Result
Per-key rate limit	HTTP 200 that lies — field silently dropped, GET reads rateLimit: null. The success code is the trap.
filters:error_messages	HTTP 400 "You do not have that feature enabled" — plan-gated, not absent. This is the one lever that would reach installs that never update. Revisit first if the org ever moves to Business.
Generic inbound filters	HTTP 204, works — but the only ids are browser/crawler/localhost. None can match a React Native error.
Spike protection	Already enabled on every project (quotas:spike-protection-disabled = false), and it did not fire because this is sustained baseline volume, not a spike. Previously recorded as "403 / unavailable", which invites spending a plan upgrade on a feature that is already on and already ineffective.

Verification

• scripts/sentry-volume-report.test.mjs — 8 new tests, including one that parses the real docs/playstore.md (so the table drifting breaks CI, not the 08-17 read) and one that pins the exact bad window from today.
• 4 new tests in scripts/noise-gate-report.test.mjs for the UNGRADED paths and the baseline choice.
• Full suite: 304 pass, 0 fail.
• Both scripts run live against Sentry; output in the commit message and above.

[dzianisv]

Auto-closed when age-105-uptake-normalized-verdict was deleted on the #175 squash-merge. Branch rebased onto main and reopened as #178 — same commit content.