ci: Gate registry CI on what actually changed

Related to #7 (section 2/3) and #8.

CI currently fans out over the whole module set on any change. This issue covers the selection machinery that decides *what* to run, for both the existing integrity/hash checker and (once #8 lands) tier 2 verification.

**Raise against `main`.** The verify PR (#10) has not landed, so this should include a **stub** where verification will be invoked — but the selection machinery itself should be complete and working. The existing hash checker must also be governed by the same algorithm.

## Selection rules

| trigger | what runs |
|---|---|
| PR, module change | changed `{module, version}` only |
| PR, infra change (`verify/**`, workflows) | latest of every module (+ any module changes in the PR) |
| push (postsubmit) | latest of every module + changed-and-not-latest |
| nightly (if scheduled) | latest of every module — no changed clause, there is no range |

"latest of every module" is the same selector for infra-change PRs and postsubmit — one implementation, two callers. It should be a single function taking the version list as input, so the set can be widened later without a rewrite (see *Future* below).

## Diff basis

- **push** — diff the last commit (`before...after`)
- **PR** — diff against the shared ancestor (`origin/main...HEAD`)

## Definition of "latest"

Last entry in `metadata.json` `versions`.

`versions` is append-only (per #7 section 4) so array order is insertion order. This is deliberate: the `.envoy` suffix is not semver-comparable, so naive sorting misbehaves. Anything smarter needs a real version comparator — not now.

## Path-class gating

A change under `modules///` is not uniformly interesting:

- `source.json`, `patches/**`, `overlay/**`, `MODULE.bazel` → run
- `metadata.json` only → skip verification
- `presubmit.yml` → run (it changes what gets built)

## Infra changes must fan out

If a PR touches `verify/**` or the workflows, the changed-modules diff is empty and verification runs **nothing** — so a PR can break the harness and green-light itself. Changes to infra paths must therefore trigger the latest-of-every-module set.

## Also

- `workflow_dispatch` with module/version inputs, so a single module can be re-run without pushing a commit (cf. the qatlib failure found during #10 bring-up)
- fan-out cost: ~80 modules × N bazel versions. Consider `max-parallel` and/or leaning on RBE. Note a shared disk cache across postsubmit jobs would undermine the cold-build property that postsubmit is testing.

## Future — active non-latest versions

Once module freeze lands, "changed and not latest" becomes unreachable for released versions by construction, so that clause only fires for unreleased/in-progress versions and the postsubmit set converges on latest-per-module.

The gap that leaves: a frozen version still active on a release branch is never re-tested, so upstream tarball rot or bazel-version breakage in it goes unnoticed until a branch build hits it. Freeze guarantees registry *content* cannot drift — not that the world around it hasn't.

Eventually worth marking active-but-not-latest versions explicitly (a sibling key in `metadata.json`, or derived from what Envoy release branches pin) and folding them into the postsubmit set. `versions` being append-only means adding a sibling key later is cheap. Out of scope here — just don't paint the selector into "latest is the only testable thing".