patches: retire pre-v1.10.0 series and make the matrix an allowlist

v1.10.0 carries upstream CVE fixes that the older releases predate, so
stop building them. Their series move to patches/archive/<tag>/ rather
than being deleted — still available for a deliberate rebuild, just not
shipped — and ci/support-matrix.yaml now lists v1.10.0 alone.

Dropping the matrix entries was not enough on its own. Two gaps made
"not built" untrue:

* apply-patches.sh only consulted the matrix `if command -v yq`, and the
  stock golang CI container has no yq — so in CI the registry was never
  actually read. The tag fell through to patches/<tag> every time.

* An empty or missing patch directory was a warning and exit 0, i.e.
  "building vanilla upstream". Archiving the directories would therefore
  have made a dispatch for v1.8.0 publish an un-de-branded, unpatched,
  CVE-vulnerable build under this project's release name — the exact
  outcome we are trying to prevent.

So the matrix is now an enforced allowlist: a tag it does not list exits
1, as does a patch directory with no patches in it. It is parsed with yq
when present and with a small awk parse otherwise, so the allowlist holds
in the CI container too. If the parse ever broke, an unmatched tag is
refused rather than built, so the failure mode stays closed.

PATCH_DIR remains the one bypass, and is now the documented way to
rebuild an archived series on purpose. That path also needed a fix: the
patch list is globbed before we cd into the source tree, so a relative
PATCH_DIR — the form the new error message suggests — globbed fine and
then failed in git am. PATCH_DIR is now resolved to an absolute path,
with a missing directory reported as such.

Also re-pointed the runnable examples in README.md, ci/run.sh and the
workflow's dispatch hint from v1.5.0 to v1.10.0; following them verbatim
would now hit the refusal.

Verified by exercising every branch: v1.10.0 applies; v1.8.0 is refused
with exit 1; PATCH_DIR=patches/archive/v1.8.0 rebuilds the archived
series; an empty directory and a nonexistent one are both refused. The
awk parser was checked against defaulted `patches:` fields, several tags
sharing one directory, and comment lines containing decoy `- tag:` text.
All seven archived patch files are recorded as pure renames.

Note: existing published releases for the retired versions stay
downloadable until deleted by hand in Gitea.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

patches/archive/README.md

@@ -0,0 +1,47 @@
+# Archived patch series
+
+Patch sets for upstream versitygw releases this project **no longer
+builds**. They are kept for reference and reproducibility, not because
+they are safe to ship.
+
+| Patch set | Contents                                                  |
+|-----------|-----------------------------------------------------------|
+| `v1.8.0/` | `0001-webui-debrand.patch`, `0002-webui-dark-theme.patch` |
+| `v1.7.0/` | `0001-webui-debrand.patch`, `0002-webui-dark-theme.patch` |
+| `v1.6.0/` | `0001-webui-debrand.patch`, `0002-webui-dark-theme.patch` |
+| `v1.5.0/` | `0001-webui-debrand.patch`                                |
+
+## Why these are not built
+
+`v1.10.0` carries upstream CVE fixes that these releases predate.
+Building them would publish known-vulnerable gateways under this
+project's release name, so their tags were removed from
+`ci/support-matrix.yaml`. That matrix is an allowlist —
+`ci/apply-patches.sh` refuses a tag it does not list, so neither a tag
+push nor a workflow dispatch can rebuild one by accident.
+
+Releases already published for these versions are **not** removed by
+archiving the patches. Delete them by hand in Gitea if they should no
+longer be downloadable.
+
+## Rebuilding one anyway
+
+If you genuinely need an archived build — reproducing an old report,
+bisecting a regression — point `PATCH_DIR` at it instead of re-adding
+it to the matrix:
+
+```bash
+VGW_TAG=v1.8.0 bash ci/clone-source.sh
+PATCH_DIR=patches/archive/v1.8.0 VGW_TAG=v1.8.0 bash ci/apply-patches.sh
+VGW_TAG=v1.8.0 bash ci/build.sh
+```
+
+Don't publish the result to a release unless you mean to ship a
+vulnerable build.
+
+## Un-archiving
+
+To return a version to the supported set, `git mv` its directory back
+to `patches/<tag>/` and add its row to `ci/support-matrix.yaml`. Rebase
+the series onto the tag first if upstream has moved — see
+[../../docs/multi-version-pipeline.md](../../docs/multi-version-pipeline.md).