refactor(i18n): add locale dictionary parity tests - #50835

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

I opened a version of this earlier and the bot closed it as a duplicate of this PR, which was the right call. Two of the three changes I had made are worth having here, and I would rather not open a competing PR for them.

The missing-key baseline will not survive contact with the codebase. Item 3 in the issue asks for a count that never rises above a constant (app 418, ui 51). English gains keys with every feature PR, so a fixed number fails on the next English string added, and it also fails on the two translation PRs currently open (#51708, #53174) whenever a locale gains a key before English does. A ratio survives that: each locale keeps at least 80% of the English key count. The least complete locale on dev is at 84.6%, so there is room for English to grow before the floor bites.

Checking every locale is barely more work than checking two. The loop over locales already exists for the baseline; running placeholder and subset checks across all 62 app locales and 61 ui locales instead of only zh and zht costs the same traversal. Today both packages report zero placeholder mismatches, so a wider check passes rather than finding work.

Item 4 does hold right now. zh and zht carry identical key sets in both packages, 858 keys each in the app package and 248 in ui, so the assertion can be added as written.

One blocker is separate and needs a small PR before the subset assertion can pass: 19 app locale dictionaries still define four key families English dropped, session.question.pending, session.background.runningCount, session.background.shell and session.background.subagent, which is 116 unreachable entries. I filed #56610 and opened #56611 to remove them. Comparing keys by plural family rather than exactly is also needed, otherwise the legitimate .few / .many variants read as unknown.

Happy to test or rebase anything here if that is easier than rewriting it.