ci(ai-validation): revert DB-download tag pin to latest:true

CRITICAL REGRESSION fix. PR #1969 changed the reference-DB download
from `latest: true` to `tag: ${{ env.REVIEWER_REF }}` (set to
`reviewer-v1.0.1`). Verification post-merge showed that:

- The `reviewer-v1.0.1` tag exists but has **no GitHub release**
  attached:

      $ gh api /repos/VyOS-Networks/vyos-docs-opus-reviewer/releases/tags/reviewer-v1.0.1
      {"message": "Not Found", "status": "404"}

- Reference DBs are published to a separate release stream by the
  matrixed `rebuild-reference` workflow, tagged
  `ref-db-<UTC-timestamp>` (e.g. `ref-db-20260510-193946`). The
  reviewer Python package and the reference DBs have independent
  release cadences.

`robinraju/release-downloader` with `tag: reviewer-v1.0.1` therefore
404s. The download step has `continue-on-error: true` so the run
proceeds, but the fail-closed gate at "Fail if reference DB missing
while MyST files are in the diff" then errors every validate run on a
PR with MD changes.

Our own recent test PRs (#1947 / #1956 / #1957 / #1968 / #1969 / #1970
on rolling, plus the circinus/sagitta backports) all happened to be
infrastructure-only — `has_md_changes` was `false`, validate was
skipped at the job level, and the DB step was never invoked. The
regression was therefore invisible until the next real `.md`-changing
PR would have failed red.

Reverting to `latest: true` is the correct behavior. The reference DB
schema is intentionally backwards-compatible across reviewer Python
releases; the freshest DB is always usable. If the schema ever
changes incompatibly, the way to opt out is bump `REVIEWER_REF` and
the new reviewer code will refuse to load an older DB at the
fail-closed gate — _exactly_ what we have today, just one level up.

A paired PR on VyOS-Networks/vyos-docs-opus-reviewer/scripts/
ai-validation.yml ([#15](https://github.com/VyOS-Networks/vyos-docs-opus-reviewer/pull/15))
applies the same revert + bumps REVIEWER_REF default to v1.0.2 so
canonical and deployed stay aligned after the next reviewer tag.

A separate companion PR will backport this revert to circinus and
sagitta to keep the workflow file byte-identical across all three
release branches.

1 files changed, 11 insertions, 5 deletions

diff --git a/.github/workflows/ai-validation.yml b/.github/workflows/ai-validation.yml
index d5f1160f..c19f7737 100644
--- a/.github/workflows/ai-validation.yml
+++ b/.github/workflows/ai-validation.yml
@@ -323,11 +323,17 @@ jobs:
         uses: robinraju/release-downloader@28fc21f50d76778e7023361aa1f863e717d3d56f # v1.13
         with:
           repository: VyOS-Networks/vyos-docs-opus-reviewer
-          # Pin the DB to the same release tag as REVIEWER_REF so a future
-          # reviewer-v1.x.x release with a schema change cannot be silently
-          # picked up while the pinned reviewer code still expects the old
-          # schema. Reproducibility > recency for this artifact.
-          tag: ${{ env.REVIEWER_REF }}
+          # latest: true is correct here. Reference DBs live in their own
+          # `ref-db-<timestamp>` release stream produced by the matrixed
+          # rebuild-reference workflow — NOT attached to the `reviewer-v1.x.x`
+          # release that REVIEWER_REF pins. A `tag: ${{ env.REVIEWER_REF }}`
+          # form would 404 (the reviewer-v1.x.x tag has no GH release with
+          # DB assets). The reference DB schema is intentionally backwards
+          # compatible across reviewer Python releases; the freshest DB is
+          # the right choice. If the DB schema ever changes incompatibly,
+          # bump REVIEWER_REF in the consuming workflow and the new code
+          # will refuse to load an older-format DB at the fail-closed gate.
+          latest: true
           fileName: reference-db-${{ steps.branch.outputs.vyos1x }}.tar.gz
           out-file-path: .reference-db
           token: ${{ steps.app.outputs.token }}