test(ui): guard the language-pack invariants that were previously unchecked

[argszero]

Summary

The ui/ layer had no automated coverage at all. Every one of the 148 existing tests is an inline #[cfg(test)] module under src/, and nothing read ui/. So three classes of defect were only detectable by eye:

• key-set drift between the zh and en packs (a key added to one language only),
• a data-i18n* attribute naming a key that does not exist,
• a T("…") literal naming a key that does not exist.

All three render the raw key name to the user (admin.emp.col.member, nav.mian, …). They are invisible until someone opens that one screen in that one language — which is exactly the kind of thing a test should be holding, not a reviewer's attention.

This adds src/i18n_pack.rs, compiled only under cfg(test) so its include_str!-embedded front-end sources never enter the release binary. No production code is touched and no dependency is added (the repo has no ui/package.json, so the JS toolchain is not available on purpose — the scan is written directly).

Related Issue

None — this is a small, self-contained test addition, which CONTRIBUTING.md explicitly welcomes as a direct PR ("外部贡献者同样欢迎：开 Issue 或直接 PR").

Changes

• src/i18n_pack.rs (new) — the invariant tests
• src/main.rs — one #[cfg(test)] mod i18n_pack; declaration
• No configuration or data-structure changes, so no example-file updates are needed

Four assertions:

1. the zh and en packs contain exactly the same key set;
2. neither pack contains a duplicate key (the later definition silently wins);
3. every data-i18n / -ph / -title / -label attribute resolves in both packs;
4. every T("literal") resolves in both packs, excluding dynamic concatenation prefixes such as "share.day." (which expands to share.day.1….7).

Notes on the extraction, since it is the part that can silently lie

• Byte scan, not a line-anchored regex. share.day.1….6 share one source line, so line anchoring reports 770 of 775 keys. A check that under-counts is worse than no check, because it looks like it passed.
• The pack region ends at the object literal's own closing brace, not at the later window.I18N export — the export sits thousands of characters further on, passed the runtime code, and scanning through it reads the ternary current === "en" ? "en" : "zh-CN" as an object key named en.
• Expected counts are asserted as positive controls, and a failed extraction panics instead of continuing. A truncated extraction yields empty sets, and a key-set equality assertion passes on two empty sets. That is a real failure mode I hit while developing this.
• checker_detects_injected_defects is a negative control: with both packs read correctly, it injects a removed key and a misspelled key and asserts the checker reports them — so the checker is shown to be capable of failing.

Tests

• cargo test — 153 passed (148 existing + 5 new), 0 failed
• cargo fmt --check passes
• cargo clippy --all-targets reports nothing for the new file
• New tests added (this PR is entirely tests)

Verified beyond the suite: injecting a defect and re-running makes the corresponding assertion fail with the offending key named, and restoring it returns the suite to green — e.g. renaming common.points in both packs leaves the key counts (775/775) and parity intact, yet both resolution tests fail with 以下 … 不存在：["common.points"]. That isolates the resolution check from the size controls.

Checklist

• Branch name follows the convention (test/…; the guide lists feat//fix//docs//refactor/ and this is none of them, but adding a test is precisely the Conventional Commits test type the guide sanctions)
• Commit message uses Conventional Commits (test(ui): …)
• Single responsibility, minimal diff: one new file plus one module declaration