Nothing fails when a shipped locale's catalog is damaged or dropped from the package

Summary

A shipped locale's catalogs can be damaged as a whole, or dropped from the VSIX entirely, without any check failing — and the localization test suite that would catch adjacent regressions is never run automatically.

Impact

Users of the shipped locales (es, zh-cn, zh-tw) would see English where they expect their own language, and nothing in the build or the test suites would say so first. Four separate gaps:

• Whole-file damage is invisible. Catalog validation checks each message on its own — unknown keys, empty values, placeholder parity, plural syntax — so it accepts a catalog that came back from an import with its entries equal to the English source, or with a large part of the source missing. Today the shipped catalogs already carry 177 (es) and 97 (zh-cn, zh-tw) entries byte-identical to their English original, and 61 plural branches Chinese can never select. Whether that is a translator's deliberate choice or import damage is currently unanswerable, because nothing records it.
• A half-shipped locale passes. Each locale has two catalogs, one for runtime messages and one for the manifest, and nothing requires both. A locale missing one renders part of the UI translated and the rest English.
• Packaging is unverified. The rules deciding what goes into the VSIX apply only when the extension is packaged, which never happens on a pull request. The E2E suite cannot cover it either, by construction: it runs the extension from a directory, where those rules have no effect at all. A catalog dropped from the package would keep every check and every test green and reach users as an untranslated UI.
• The localization test suite never runs. pnpm run test:localization is documented as covering extraction, catalog validation, host and browser initialization and the literal-message lint rule, but no job and no other script invokes it, so a regression in any of those goes unnoticed. Separately, part of it fails on Windows for anyone who does run it by hand, which is how it can be documented and broken at the same time.

Validation

• A catalog whose entries are replaced by their English source, or one missing a significant share of the source messages, fails the build.
• A locale that ships only one of its two catalogs fails the build.
• Removing a catalog from the package, or removing the rules that keep the generated pseudo catalogs out of it, fails a pull request.
• The localization suite runs in CI, and passes on Windows as well as Linux.

Risk

The first two checks have to compare against recorded numbers, so they need an explicit way to re-record them: a translation batch that legitimately keeps a term in English, or a prune that drops many stale entries, must be a deliberate update rather than a silent pass or a permanent red. Requiring complete coverage would be wrong in the other direction — English is the documented fallback for a missing message, and every newly added English string temporarily lowers every locale's coverage until the next import lands.

Related

#5858 covers the separate gap that no end-to-end run ever loads a real translated catalog.