catalogParity red on main: ko.json still carries the retired bucket Storage keys and lacks the 29 inventory ones

[chenmingwei23]

Problem

catalogParity fails on main — the Korean catalog is desynced from en for the whole Storage screen, so Frontend Tests is red for every open PR that touches website/:

FAIL src/i18n/catalogParity.test.ts > catalog parity > ko > has no key missing relative to en
  missing 29 key(s), e.g. pages.sessionStorage.background_group, pages.sessionStorage.bulk_selected,
  pages.sessionStorage.cannot_delete_resumable, pages.sessionStorage.cannot_delete_running, ...

FAIL src/i18n/catalogParity.test.ts > catalog parity > ko > has no key absent from en
  36 stray key(s), e.g. pages.sessionStorage.batch_detail, pages.sessionStorage.bucket_30_90d,
  pages.sessionStorage.bucket_30_90d_hint, pages.sessionStorage.bucket_7_30d, ...

Reproduced on a pristine kirocrew/main i18n tree (git checkout kirocrew/main -- website/src/i18n/ in an unrelated worktree, then run that one test): 2 failed | 75 passed (77), byte-identical to what the PR merge commits show.

Root cause

The two assertions are one event, not two bugs. ko.json was translated against the bucket-based Storage screen, and the inventory-model redesign replaced that key set without re-syncing Korean:

• the 36 "stray" keys are the retired bucket vocabulary (bucket_7_30d, bucket_30_90d_hint, batch_detail, …) that only ko still carries;
• the 29 "missing" keys are the inventory vocabulary en gained (bulk_selected, clear_selection, cannot_delete_running, cannot_delete_resumable, background_group, …) that ko never received.

So this is the rename half of a key migration applied to en and not to ko. ko is a comparatively new locale, which is why the gap did not exist when the redesign landed and appeared as soon as Korean was added to SUPPORTED_LANGUAGES.

Impact

Two layers:

1. Product — a Korean user on the Storage page gets English for all 29 new strings, including the destructive-action confirmations (cannot_delete_running, cannot_delete_resumable). Those are exactly the strings you least want falling back to a language the user did not choose.
2. CI — catalogParity runs in Frontend Tests, so this reds an unrelated PR's Frontend Tests → Coverage Gate → PR Readiness chain. Every author now has to prove the failure is not theirs before they can call their own PR green.

Suggested fix

Owned by whoever landed the inventory Storage redesign, since the Korean copy needs to match that screen's final vocabulary: delete the 36 retired bucket keys from ko.json and add the 29 inventory keys. Nothing else in the catalog is involved.

Worth considering separately: the guard catches the desync only once a locale is supported, so a key migration can sit latent in an unsupported locale and surface later as someone else's red build. Running parity over every catalog present on disk — not just SUPPORTED_LANGUAGES — would have failed this in the redesign's own PR.

Found while driving #2225, which touches no pages.sessionStorage key. (That PR did have its own genuine ko gap — 6 findingCard keys it added — and that half is fixed on its branch.)

[k33bz]

Grabbing this; the 36 retired bucket keys deleted and the 29 inventory keys translated, with wording taken from the terms already in ko.json (세션 스토리지, 턴, 선택 해제, 오래된순, 회수, 휴지통으로 이동) rather than a dictionary. trash_summary and trash_batch_reason recover their Korean from the retired batch_detail, which the redesign split in two.

Flagging your ownership note: you suggested this belongs to whoever landed the inventory redesign, and I agree the final wording should be theirs. I'm only opening it to unblock main. Feel free to reject/overrule.

Not including the broader fix you proposed (running parity over every catalog on disk rather than only SUPPORTED_LANGUAGES). That changes a shared gate and could break other locales, so it deserves its own PR. I'm not the one to decide that.

Opened as #2306. Worth noting #2299 cites this same catalogParity ko failure as a pre-existing blocker that reproduces on clean main, so this unblocks that PR's Frontend Tests too. It needs a maintainer to approve the workflow runs. First-time-contributor gate, so none of the pull_request checks have started yet and PR Readiness is red purely on missing results.