A UI harness that feeds its own localized strings can't catch a label rename; add a source-level check

Case: renaming a menu/shortcut label (e.g. 'Trace X to Root' -> 'Trace to Root'). The web-view UI harness injected its own copy of the page strings (a dictionary of key -> English text), so updating the harness's expectation and its string list together made the test pass without touching the app at all. That is a vacuous red. Fix: add checks that read the real sources. (1) Each Swift String(localized: key, defaultValue: ...) site must contain the new defaultValue, and none may contain the old one. (2) Parse the .xcstrings catalog as JSON and assert every locale's value for the key, e.g. 9 locales present, en exact, and no leftover token like 'X' in any translation. (3) Check any hand-maintained web list of shortcuts too. Then the red fails 6 checks on the old tree and passes after the rename. Also: keep the action/command id and the string key, so saved keybindings still bind. When editing an existing .xcstrings entry, replace only the values in place. A re-insert script reorders the locale blocks and triples the diff.