Run the gates on a tag, so beta criterion 2 can be satisfied (#833)

[OffgridwithJD]

Closes #833. Two trigger blocks, 25 lines, all of it comment except four.

The gap, measured

design/RELEASE_PLAN_1.0.md asks for a green matrix "on the tag itself, not on a
branch", and names both this repository's deep gate and its sanitizer gate. Nothing
fired on a tag. Counting workflow runs whose head_sha is the tagged commit:

tag	runs	detail
v1.0-dev	0	nothing has ever run against that commit
v1.0-alpha	2	both event=push ref=main
v1.0-alpha2	8	all ref=main; 2 success on the tag day, 6 nightly failures 08-19 to 08-24, which were the environment red #741 closed on 08-25

Not one run is attributed to a tag. Release provenance today is "some runs against
main that happen to share a SHA", and for v1.0-dev there are none at all.

alpha3 is cut on Monday, so without this the tag is cut ungated again.

Proven to fire, not merely written

A trigger that never fires looks exactly like a quiet board, which is the whole content
of #833; shipping it unverified would repeat the defect one level up. So I pushed a
throwaway tag v0.0.0-tagtrigger-probe at this commit on my fork:

nightly deep gate  event=push  ref=v0.0.0-tagtrigger-probe  sha=41e56afe
build and test     event=push  ref=v0.0.0-tagtrigger-probe  sha=41e56afe

Both workflows fired, on the tag ref, at the tagged commit. The nightly run came back
skipped with all four jobs skipped, which is the fork guard behaving exactly as
predicted below. The CI run was cancelled once it had started (the trigger was the
question, not the matrix) and the probe tag deleted; zero tagtrigger refs remain.

Three things checked before changing anything

actions/checkout takes the triggering ref, so a tag run builds the tag rather
than a branch that happens to contain it.

Concurrency does not cancel anything. ci.yml groups on ci-${{ github.ref }}
with cancel-in-progress: true; a tag ref is not refs/heads/main, so the tag run and
the main run are different groups. nightly.yml is group: nightly with
cancel-in-progress: false, so a tag run queues behind a scheduled one instead of
killing it.

The job guards need no change. Every nightly.yml job carries
if: github.event_name == 'workflow_dispatch' || github.repository == 'commandprompt/pgcolumnar'.
A tag push on the canonical repository satisfies the second clause, so the jobs run
there; a fork still skips them, which is what the probe demonstrated.

The duplicate CI run against a commit already built on main is the point rather than
waste: it is what binds a green result to the release artifact.

Gate

harness_selftest is 168 of 168, and it is the relevant one: selftest/220 and
selftest/240 both read .github/workflows/, so this change is genuinely exercised
rather than merely adjacent to the suite. I checked that before deciding what to run
instead of assuming a workflow edit is untested.

GATEBLOCK

[jdatcmd]

Approved. I checked each factual claim the comments make rather than reading them,
because every one of them is load-bearing for whether a tag run does any work.

Premise, that no workflow has ever fired on a tag. Confirmed against the API: the
repository holds three tags (v1.0-dev, v1.0-alpha2, v1.0-alpha) and no workflow
run has a tag as its head_branch. The gap is real, not inferred from the absence
of a v1.0-dev run alone.

The claim I most wanted to be wrong about is the nightly job guards, because the
failure it would produce is a green run that did nothing. All four jobs (suites,
sanitizer, coverage, upgrade-guard) guard on:

if: github.event_name == 'workflow_dispatch' || github.repository == 'commandprompt/pgcolumnar'

The second clause is true for a tag push on the canonical repository whatever the
event is, so the jobs run rather than skip, and a fork still fails both clauses on
a push. The comment is right and needs no change.

Concurrency, both directions:

• ci.yml is group: ci-${{ github.ref }} with cancel-in-progress: true. A tag ref
  and refs/heads/main are different groups, so the tag run and the main run do not
  cancel each other.
• nightly.yml is group: nightly with cancel-in-progress: false, so a tag run
  queues behind a scheduled one rather than killing it.

"actions/checkout takes the triggering ref" holds because nothing overrides it:
no checkout step in either workflow sets ref:. The only with: on any of the
seven is fetch-depth: 0. So a tag run builds the tag's own tree, which is the
whole point of the criterion.

ci.yml has no job-level guards at all, so nothing skips there either.

Full matrix green on the head: 9 build legs, shellcheck, and both suites legs
(PG17 and PG18). Suites, not only build checks.

One limitation, which I do not think blocks this but should be on the record. The
change cannot be exercised by its own pull request. A pull_request run never
pushes a tag, so nothing in this green matrix demonstrates that a tag push
triggers anything, and the usual removal proof is unavailable: delete both hunks
and CI is exactly as green. That is inherent to a trigger change rather than a
defect in the work here.

So the verification is owed after merge, not before. Push a throwaway tag on the
canonical repository and confirm two things: that runs appear with the tag as
head_branch, and that the nightly run's jobs actually executed rather than
skipped. The second is the one that would expose a guard I read wrongly. Until
that is done, criterion 2 is satisfiable in principle rather than demonstrated.