[MumuTW]

Implements proposal 1 of #8584. One JSON file, no product code, no test changes.

What this does

Runs node scripts/check/check-file-size.mjs --update — the shrink-only ratchet path — apparently for the first time.

	frozen (prod)	testFrozen
entries removed (fell to ≤ cap 800)	14	0
entries lowered to measured size	60	17
entries raised	0	0
entries added	0	0

cap and testCap untouched. All 55 _rebaseline_* documentation note keys preserved. Verified by a key-by-key diff of the pre/post JSON rather than by reading the diff, so "zero raised" is a measured claim.

The gate is green before and after. This is a pure tightening, not a base-red repair — nothing here unblocks anything, it just stops the ceiling from being a one-way valve.

Why it was needed

--update is shrink-only by construction (if (loc <= cap) delete frozen[file]; else frozen[file] = loc), so it can't be abused. But grepping .github/workflows/ for --update finds only wiki-sync.yml (unrelated) and ci.yml:221, which runs check-quality-ratchet.mjs --require-tighten — a different script against a different metric. Neither check:file-size --update nor check:complexity-ratchets --update is invoked anywhere in CI.

The result is an asymmetry: raising a cap is a manual ten-second edit and the fastest way to unblock a PR; lowering requires a command that is nobody's job. So caps outlive the code that earned them:

file	actual	old cap	ratio
src/shared/validation/schemas.ts	19	2,523	132.8×
src/shared/constants/pricing.ts	40	1,662	41.5×
open-sse/config/providerRegistry.ts	279	4,731	17.0×
src/shared/constants/providers.ts	480	3,276	6.8×
src/shared/constants/sidebarVisibility.ts	293	1,198	4.1×
src/lib/evals/evalRunner.ts	301	961	3.2×

A 19-line file carrying a 2,523-line cap isn't a gate on that file — it's permission to add 2,504 lines with the gate silent. Every one of those numbers is a decomposition that succeeded and whose gain was never banked.

The part worth reading twice

Three of the entries tightened here had already been decomposed once, and the gain was never recorded:

file	old cap	actual now
src/lib/providers/validation.ts	4,523	958
open-sse/services/usage.ts	3,454	1,065
open-sse/services/tokenRefresh.ts	2,249	999

Those are the same three files being decomposed a second time right now in #8546, #8545 and #8547. Round one took them from ~4.5k/3.5k/2.2k down to ~1k and left the caps at the round-zero high-water mark, so the ledger reflects none of it. That is the clearest illustration I found of why the baseline reads as pure inflation: the shrinks happened, they were simply never written down.

Largest single tightenings in this diff, for the record:

4523 ->  959  (-3564)  src/lib/providers/validation.ts
3454 -> 1066  (-2388)  open-sse/services/usage.ts
2249 -> 1000  (-1249)  open-sse/services/tokenRefresh.ts
1873 -> 1044  ( -829)  open-sse/executors/grok-web.ts
3777 -> 3097  ( -680)  open-sse/handlers/imageGeneration.ts

For comparison, complexity-baseline.json records ~37 rebaseline notes since 2026-06-13 with exactly one decrease in it (−1 line). This commit moves 91 entries down.

Known residue, deliberately not fixed here

Three entries sit at exactly their frozen value and far below the 800 cap — ProviderDetailPageClient.tsx 798, useProviderModels.ts 155, useProviderSettings.ts 264. They cannot leave the baseline, because --update only reaches the delete branch when the file also shrank in that same run (loc < frozen); an entry already equal to its cap never qualifies. That is a one-line change to the gate's logic and doesn't belong in a mechanical banking commit, so it's noted in #8584 instead.

webProvidersA.ts is a legitimate keep: it shrank 809 → 801 but 801 is still above the 800 cap, so it stays frozen at 801, which is correct.

Scope

Only check:file-size --update. I did not run check:complexity-ratchets --update, because complexity is currently above its baseline on this tip (2169 vs 2130) and the shrink-only path would refuse to write — that one is #8580's problem, not this PR's.

Verification

• npm run check:file-size — green before and after (168 arquivos congelados after, was 182 keys / 127 real files before; now 113 real files + the 55 notes).
• Prettier clean.
• No production code, no tests changed, so no test additions required — same shape as fix(quality): repair release/v3.8.49 base-red gates #8561.

Refs #8584