fix(ci): re-measure the drifted t-chunk bundle ceiling

[CrysisDeu]

Problem

The t chunk (i18n runtime + English catalog) ceiling is 777 KB. Pristine main @ 9af9543b0 builds it at 795,127 B = 776.5 KB — 0.07% headroom (verified locally with npx vite build --mode analyze + node scripts/check-bundle-size.mjs; same t-lertjcbp.js content hash as main's own CI run). Any PR adding a normal set of English keys now fails Bundle Size Gate on its merge ref while main's own gate stays green — first seen on #8307 (+40 keys, 778.9 KB).

This is the third recurrence the file's own comment describes (#8412 for t, #8519 for App, #8935 for all): a ceiling that drifted to <1% headroom fails on routine string growth instead of on the new library it exists to catch.

Change

One line: t: 777 * KB → t: 815 * KB (776.5 KB × 1.05, matching the 5% convention used by the all and App entries), plus the re-measurement note.

Verification

• node scripts/check-bundle-size.mjs on pristine main: 817 chunks within budget.
• npx eslint scripts/check-bundle-size.mjs: clean.

Unblocks #8307.

Pattern harvest

Rule candidate: ci (main-ratchet-audit.yml)
Pattern: an allowlisted CHUNK_BUDGETS ceiling drifts to <1% headroom on main, so the next feature PR with routine string growth reds Bundle Size Gate on its merge ref while main's own gate stays green. Third occurrence in four days (#8412 t, #8519 App, #8935 all, now t again). The audit that already runs on every push to main can build once, compare each allowlisted chunk against its ceiling, and open/flag a re-measure when headroom falls under ~1% — catching the drift before it lands on a contributor's PR.

[github-actions]

Opus 4.8 Review — ✅ no blocking findings

Reviewed 16d4ca891a663417c013024c5f30f5a2a89440d1 — this comment is updated in place on each push.

Review details

No findings.

[OPUS-REVIEWED] 16d4ca8

Verdict parsed from the review's SHA-scoped output markers for commit 16d4ca891a663417c013024c5f30f5a2a89440d1.

False positive or not applicable? A repository writer can comment:
/ai-review override fable 16d4ca891a663417c013024c5f30f5a2a89440d1: <one-sentence reason>

[github-actions]

UX Review (Fable 5) — ✅ PASS

UX-level review of 16d4ca891a663417c013024c5f30f5a2a89440d1 — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

UX-Verdict: PASS

CI-only bundle-ceiling bump; no user-visible surface changes, so nothing for a user to see or misread.

[UX-REVIEWED] 16d4ca8

[github-actions]

Design Review (Fable 5) — 🟡 CONCERNS

Design-level review of 16d4ca891a663417c013024c5f30f5a2a89440d1 — updated in place on each push. A BLOCK verdict blocks PR readiness; PASS/CONCERNS are advisory.

Design-Verdict: CONCERNS

The bump is correct per the file's own convention, but the file itself proves that convention now has a ~4-day half-life for catalog chunks.

Watch

The previous t bump (740→777 KB, comment: "so the next English string does not re-trip this for the third time") was consumed in four days — "~36 KB of English strings in four days" per this diff — and this is the third ceiling re-measure in this file inside a week (App 09-04, all 09-06, t now). At that growth rate 815 KB trips again within ~a week, and each re-baseline absorbs whatever landed during the drift window into the new floor, so a real regression that arrives between bumps gets ratified rather than caught. A static absolute ceiling cannot distinguish the string growth it must tolerate from the library jump it exists to catch when the two differ by only a few percent per week.
Clears when: catalog chunks (t, all, App) get a growth-aware check (e.g. delta vs the PR's own base ref, or a per-PR increment cap) so routine string growth never drifts the gate — or evidence the 36 KB/4-day rate was a one-off burst.

Suggestions

• The re-baseline comment asserts the 36 KB is "English strings" without the byte-identical-to-base attribution the 09-04 bump performed; make growth-composition verification part of the bump ritual, or the ritual is how a library sneaks in.

[DESIGN-REVIEWED] 16d4ca8

[github-actions]

GPT 5.6 Review — ✅ no blocking findings

GPT 5.6 completed its review of 16d4ca891a663417c013024c5f30f5a2a89440d1 and found no blocking issues.

This comment is updated in place on each push.

Review details

No findings.
[GPT-REVIEWED] 16d4ca8

False positive or not applicable? A repository writer can comment:
/ai-review override gpt 16d4ca891a663417c013024c5f30f5a2a89440d1: <one-sentence reason>

[iamwhatever]

Tier 1 auto-approve: chore / build tooling (1 file). Criteria: no conflict, no requested changes, security path denylist clean, design-doc gate clean, SAST annotations clean, security checklist all-NO, AI reviewers green. Category: CI bundle-size budget for the t-chunk re-measured from 777 KB to 815 KB after main drifted to 776.5 KB (0.07% headroom); a single constant in website/scripts/check-bundle-size.mjs, no runtime impact.

[dwu96]

Tier 1 auto-approve: chore / build tooling (1 file). Criteria: no conflict, no requested changes, security path denylist clean, design-doc gate clean, SAST annotations clean, security checklist all-NO, AI reviewers green. Category: CI-only budget re-measurement in website/scripts/check-bundle-size.mjs -- the t-chunk ceiling had drifted to 0.07% headroom (main alone builds 776.5 KB against a 777 KB cap), so any PR adding English strings tripped it while main's own gate stayed green; the ceiling moves to 815 KB, restoring the same 5% headroom convention the neighbouring entries already use. No runtime code touched.

[chenmingwei23]

Tier 1 auto-approve: fix/ci (1 file). Criteria: no conflict, no requested changes, security path denylist clean, design-doc gate clean, SAST annotations clean, security checklist all-NO, AI reviewers green. Category: single-line CHUNK_BUDGETS ceiling re-measure on check-bundle-size.mjs, CI-only, no runtime impact.