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