Scope release-note category validation to changed files

What does this MR do and why?

The docs-lint release-note-categories job validates release-note category tags against categories.yml (fetched live from www-gitlab-com). It ran post-merge and re-validated the entire doc/releases/ history on every change. Because category names get renamed or removed upstream over time, already-published release notes become invalid retroactively — breaking master even though nothing in those notes changed. That's why the job is currently allow_failure: true.

This MR scopes the job to only the release notes changed in the merge request:

• Moves the job from post-merge (.if-default-refs) to merge request pipelines (.if-merge-request), so a bad category is caught on the contributor's MR, before merge.
• Replaces the doc/releases/**/*.md glob with a git diff against the MR's merge base, filtered to changed doc/releases/*.md files. Exits cleanly when no release notes changed.
• Removes allow_failure: true — the job can enforce again now that it no longer trips over immutable history.

The validator script is unchanged; it already accepts a list of files.

Why this approach

Published release notes are immutable records. Re-validating them against a moving categories.yml produces failures no contributor can act on, and guarantees recurring master breakage on every future category rename. Scoping to changed files:

• Removes the recurring failure class rather than papering over each rename (a legacy-name allowlist would need manual upkeep forever).
• Aligns validation scope with the job's changes: rule.
• Requires no edits to historical release notes.

Validation

Simulated the scoped job against two real MRs:

• !239373 (merged) (AI Audit Event Report, 19.2) — passes; its categories are valid.
• !242447 (closed) (Runner Core 19.1) — fails with a single correct error (Runner Core should be GitLab Runner Core), instead of being buried under ~43 unrelated historical errors.

Related to #603549 (closed)