fix(i18n): stop xcstrings from diffing on every Xcode build

[jbergler]

Summary

• Root-caused why .xcstrings String Catalogs show a full-file diff after nearly every local Xcode build/run: Xcode auto-syncs catalogs against source (SWIFT_EMIT_LOC_STRINGS: YES) via its own IDE build path only (confirmed xcodebuild CLI never triggers it), rewriting the whole file in its own formatting and key order every time.
• Xcode's key ordering isn't alphabetical or locale-collated (looks like Swift's hash-seeded Dictionary order) and can't be reproduced byte-for-byte by outside tooling — that part is inherent and not fixable from here.
• What is fixable: the repo's own catalog writers (seed-string-catalog.py, translate-de.py, translate-it.py) each wrote catalogs via plain json.dumps(indent=2), a format different from Xcode's own — compounding noise on top of Xcode's unavoidable reordering.
• Adds Tools/xcstrings_format.py: a stable, deterministic canonical writer (sorted keys, Xcode's " : " spacing and no-trailing-newline convention, and its non-collapsing empty-object formatting), used by all three catalog-writing scripts, plus a CLI to canonicalize any catalog on demand — collapses a build-triggered working-tree diff back to real changes for a quick "did anything actually change" check.
• Adds Tools/git-hooks/pre-commit to re-canonicalize any staged .xcstrings file automatically (opt in via git config core.hooksPath Tools/git-hooks), so committed history stays diff-friendly regardless of what Xcode's local rewrite left behind.
• Documents the whole mechanism in docs/CONTRIBUTING.md.

Not in this PR: an earlier version of this PR also landed ~221 strings that Xcode's extraction had synced in from Swift source but that had never made it into the catalogs (several PRs were merged without a local Xcode compile, per project convention). CI's i18n-coverage gate correctly failed on that — full de/es/fr/pt-PT translation coverage is a standing invariant here, and those 221 strings had no translations yet. That's real, separate work, not something to auto-generate alongside a formatting fix, so it's been dropped from this PR: all four catalogs are now reformatted-only, byte-for-byte identical in content to main. The backlog itself is left for separate follow-up work with real translations.

Test plan

• cd Tools && python3 -m unittest test_xcstrings_format -v — 8/8 pass
• cd Tools && python3 -m unittest test_i18n_audit -v — 34/34 pass (untouched, still green)
• python3 Tools/i18n_audit.py --ci origin/main — green (this is what CI runs; confirmed locally after dropping the untranslated backlog)
• Verified all four catalogs are content-identical (via JSON comparison) to their main versions — this PR only changes formatting
• Verified the canonicalizer is idempotent (re-running reports "already canonical", zero diff)
• Smoke-tested the pre-commit hook end-to-end in a scratch repo: a non-canonical staged .xcstrings file is normalized and re-staged before commit
• Confirmed via direct experiment that plain xcodebuild CLI builds (macOS Strand and iOS NOOPiOS schemes) never touch .xcstrings files, including after adding a new String(localized:) call to source — only Xcode.app's own build/run path does