i18n: no coverage gate for the locales a deployment adds after zh-CN #102

Recorded while landing #18 (claude/issue-18-i18n-bundles). Not a defect today — a shape the current gate is one locale away from needing.

test/i18n-coverage.test.ts compares the derived key set against zh-CN by name:

const TARGET_LOCALE = 'zh-CN';
const chineseKeys = new Set(bundleKeys((dulyChinese as Rec)['zh-CN']));

and separately asserts that the bundles cover exactly i18n.supportedLocales. So adding ja-JP to supportedLocales plus a ja-JP.ts file would be caught by the locale-set assertion — but once the file exists, nothing checks its key coverage. A ja-JP bundle carrying ten of the 231 keys would pass every test in the file: the two directions are only ever run against zh-CN.

The fix is small and mechanical — iterate the non-source locales in dulyTranslations rather than naming one — and it is deliberately not done on #18, whose scope is the first Chinese deployment. It is filed rather than done so it is a decision on the record instead of a surprise for whoever adds the third locale.

Adjacent, same file, same shape: templateGaps() already iterates supportedLocales generically, so the email-template half of the gate does not have this problem. Only the bundle half does.

Generated by Claude Code