perf(frontend): restore warning-free production chunking after bundle regression

[seonghobae]

Finding

The current protected-main frontend has regressed past the warning-free split established by merged PR #644. This is a repository baseline regression, not something introduced only by the translation/read-model stack.

Exact evidence:

• merged perf(frontend): split conditional workspace surfaces #644 measured the application chunk at 499.09 kB minified / 138.04 kB gzip with no production large-chunk warning;
• ci: upgrade setup-node to remove Node 24 deprecation #1013 is based directly on protected main@83eba56149eb802cd63642c507c324c9976ec78e and changes only the actions/setup-node pin. Its Tests run 34641526261, frontend job 103402164101, therefore measures the current product source without a product-code delta: index-CynFsbmm.js is 551.27 kB / 161.88 kB gzip and Vite emits Some chunks are larger than 500 kB after minification;
• parent feat: establish versioned UI translation ledger foundation #929 exact 7244febf... independently measures the same 551.27 kB / 161.88 kB gzip warning;
• child feat(i18n): consume published Customer Master screen copy #932 exact c13f6c3... reaches 557.78 kB / 164.11 kB gzip, so that child adds roughly another 6.5 kB but is not the root origin of the regression;
• current Storybook build diagnostics also report about 90% of build time in plugin hooks, led by storybook:react-docgen-plugin and vite:asset. Treat that as a profiling lead, not as permission to disable diagnostics.

The production warning must not be normalized as GREEN merely because the build exits zero.

Repair contract

• profile the current protected-main entry graph and identify the additions since perf(frontend): split conditional workspace surfaces #644 that grew the eager application chunk from 499.09 kB to 551.27 kB;
• restore native dynamic-import/lazy boundaries where product semantics allow, preserving normal/loading/error/permission states, focus behavior, and accessible recovery;
• keep build.chunkSizeWarningLimit unchanged and do not suppress/filter the Vite warning;
• require an exact-head production build with no >500 kB application warning and retain measured minified+gzip chunk inventory;
• inspect Storybook plugin timing separately and optimize only repository-owned causes; do not hide PLUGIN_TIMINGS merely to make logs quiet;
• after causal source repair, run frontend tests/build/Storybook and applicable browser acceptance;
• refresh docs/product-technical-gap-baseline.md, whose frontend-delivery row still cites perf(frontend): split conditional workspace surfaces #644 as the warning-free solution, with the repaired exact protected-head evidence.

No claim is made that #929 caused the baseline regression; #1013 proves the warning is already present on current protected-main product source.

[seonghobae]

Fresh reconciliation against live open work: #995 already carries the non-duplicate source candidate for this delivery gap. Its frontend/vite.config.ts split keeps the Vite warning threshold unchanged and separates stable React/auth vendor code; the branch records a principal application chunk of about 297.96 kB minified / 87.08 kB gzip, but it also records total JavaScript around 618 kB and intentionally remains Draft/RED because durable exact-head authenticated cold buyer-path transfer/parse-compile/main-thread/DOM/p95 evidence is still absent. Do not close #1012 from the chunk split alone, and do not open a second competing split lane; evolve #995 or a no-drop successor and satisfy this issue's current-head delivery evidence contract.

There is also an evidence-lineage correction for the historical baseline. #644's PR body associates the 499.09 kB / 138.04 kB gzip observation with bundle-measurement candidate 6033728b, while the actual final PR head is b8ca223c1ea472a59c31afb11afd7fec4ffe53af. The final head commit message does confirm the native lazy split and separate chunks, but I have not recovered an exact final-head size receipt matching 499.09. Treat 499.09 as historical candidate evidence unless that exact final-head receipt is recovered. The current authoritative protected-main baseline remains the exact main-based #1013 measurement: 551.27 kB / 161.88 kB gzip with the >500 kB warning.