fix: skip already-translated keys in spark lang:find

[paulbalandan]

Description

spark lang:find decided whether a key was "new" by loading only app/Language/<locale>/<File>.php. But at runtime lang() resolves a key through the FileLocator across every namespace (framework, packages, and app). As a result, keys already shipped by the framework or a package (for example Errors.* from system/Language) were treated as new:

• --show-new listed them as missing translations.
• In write mode they were materialized into app/Language as untranslated placeholders (the dotted key string), which then overrode the framework's real translations at runtime (e.g. error pages rendering the literal Errors.pageNotFound).

This PR makes the finder compare found keys against the translations resolvable from all namespaces, mirroring how lang() resolves at runtime. A key is now considered new only when it cannot be resolved from any loaded language file. Write mode writes only genuinely-new keys plus the app's own existing keys, so framework- or package-provided translations are never copied into app/Language.

Added regression tests for both the --show-new and write paths, and a note in the localization guide.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value (without duplication)
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide