Release pipeline: verify:sources runs in no workflow, and generated release notes have no release.yml

[Seismix]

Two gaps in the release pipeline surfaced while shipping v1.8.1 (#143). Both are
small and independent; grouped here because they touch the same workflow.

Related: #134 — see the interaction note under part 1 before adding any new
required check.

1. verify:sources is never run by CI

scripts/verify-sources-zip.ts (added in #141) unpacks
royalrefresh-<version>-sources.zip into a clean directory, installs, builds,
and compares the result file-by-file against the shipped
royalrefresh-<version>-firefox.zip — reproducing what an AMO reviewer does.

It is wired into package.json as verify:sources and referenced by no
workflow. grep -rn "verify:sources" .github/ returns nothing. It did not run
on #141 (which introduced it), #142, or #143.

That matters because publish.yaml's firefox job submits
--firefox-sources-zip to AMO unconditionally. A sources archive that no longer
rebuilds to the shipped extension currently fails in AMO review, days later,
rather than in CI.

It does work — run manually against dev at 065d383 before merging #143:

14 file(s) compared; containers 110863 vs 110863 bytes
✔ Every file matches. The source archive rebuilds to the shipped extension.

Nothing is broken today; the check is simply opt-in and manual.

Options

1. A step in publish.yaml's firefox job, after pnpm zip:firefox and before
   wxt submit. Blocks a bad archive from reaching AMO at all, and reuses the
   zip that job already builds. Adds ~1–2 min to publishing only.
2. A standalone PR check. Catches it earlier, but pays the full build plus a
   nested install on every PR.

Option 1 looks like the better trade — the artifact only matters at submission
time, and that is the only place a failure needs to stop anything.

Important

Interaction with #134. If this becomes a required PR check, it must not
use on: pull_request path filters, or it reproduces exactly the deadlock
described there: skipped workflow → status never reported → PR unmergeable.
Option 1 sidesteps this entirely by living in publish.yaml, which is not a
required check. Option 2 needs #134's in-job change detection first.

2. No .github/release.yml

publish.yaml's release job ends with gh release create --generate-notes,
which has no configuration file to work from, so every PR lands in one
undifferentiated "What's Changed" list.

This only became worth fixing now. Under squash-merging, the range between two
tags on main contained a single release PR, so there was nothing to categorise.
Since #143 merges dev with a real merge commit, the range now contains the
individual PRs and categories have something to sort.

Sketch:

changelog:
    exclude:
        authors:
            - dependabot
    categories:
        - title: New Features
          labels:
              - feature
        - title: Bug Fixes
          labels:
              - bug
        - title: Maintenance
          labels:
              - dependencies
              - code tools
        - title: Other Changes
          labels:
              - "*"

Categories match on PR labels, first match wins, and "*" is the catch-all —
without it, unlabelled PRs are dropped from the notes silently.

Two things to decide alongside it:

• Whether generated notes should stay the source of the release body at all, or
  be replaced/augmented by src/assets/patches/v<version>.json, so the GitHub
  release reads the same as the extension's "What's New" popup.
• --notes-start-tag. Notes default to "since the previous tag", and there are
  no tags for v1.3.0–v1.6.0. Any release landing near that gap will pick the
  wrong starting point.

One-off note

v1.8.1's generated notes listed all 16 PRs back to #118, of which only 4 were
new. Those older PRs were squash-merged into main, so their commits only became
reachable when #143 merged dev with a real merge commit, and GitHub read them
as new in the v1.8.0...v1.8.1 range. The release body has been corrected by
hand. This does not recur: dev is now a genuine ancestor of main, so future
ranges contain only their own commits.