[l10n/automation] Manifest contract and catalog diff engine

[Chaitanya-Keyal]

Note

One of the l10n source-string automation PRs (#940, #941, #942, #943, #944). This PR has no dependencies on the others.

Description

Problem or Issue being addressed

To tell reviewers and translators what a PR changes, we need
(a) a stable, machine-checkable contract for that data and
(b) a diff between two gettext catalogs that reports only translator-meaningful changes, ignoring source-location moves and header churn.

Solution

Adds the foundation for the source-string automation:

• schema/review-manifest.schema.json -- the "review manifest" contract (JSON Schema draft 2020-12) for the data passed from the untrusted PR diff job to the trusted comment job. It is strict by design: additionalProperties: false, a const version, bounded array/string lengths, and SHA/owner/name patterns on the trust-anchor fields.
• pot_diff.py -- keys catalog entries on (msgctxt, msgid) and reports added/removed/changed strings, then assembles a manifest conforming to the schema. Counts are always exact; the per-bucket example lists are capped (and flagged truncated) so a huge diff cannot produce an unbounded manifest. The committed messages.pot is never read -- the catalog is extracted fresh from base and head source -- so the result is correct regardless of whether the committed catalog is current.

---

This pull request is categorized as a:

• Other (l10n automation)

---

Checklist

I ran pytest locally

• All tests passed before submitting the PR

(python -m pytest l10n/automation/tests -- these tests live outside the project's default testpaths and are run explicitly.)

---

I included screenshots of any new or modified screens

• N/A

---

I added or updated tests

• Yes

---

I tested this PR hands-on on the following platform(s):

• Github Actions

---

I have reviewed these notes:

• Keep your changes limited in scope.
• If you uncover other issues or improvements along the way, ideally submit those as a separate PR.
• The more complicated the PR, the harder it is to review, test, and merge.
• We appreciate your efforts, but we're a small team of volunteers so PR review can be a very slow process.
• Please only "@" mention a contributor if their input is truly needed to enable further progress.

• I understand

---

[wolgwang1729]

LGTM!