fix(lint): hard-fail on main when a release tag is needed

.pre-commit-hooks.yaml now exposes hooks to external consumers pinning
rev: <tag>, but nothing enforced that a tag actually gets cut when the
files it references change — relying on memory is exactly what this
repo's governance rules say to avoid for a repeatable, deterministic
check.

scripts/check-release-needed.sh hard-fails at pre-push, but only when
PRE_COMMIT_REMOTE_BRANCH (set by pre-commit's hook-impl) is
refs/heads/main: it diffs .pre-commit-hooks.yaml's referenced paths
against the last tag reachable from HEAD, and fails if either no tag
exists yet or something changed since. It's a silent no-op on every
other branch — hard-failing on feature-branch pushes mid-review would
force a premature tag on a commit that might not survive a
squash-merge, the exact risk the repo: local (vs. pinned self-
reference) decision in ADR-0014 already avoids for this repo's own
dev-time gate.

Verified against the real git pre-push hook path (not just the script
in isolation): simulated stdin matching git's pre-push protocol through
.git/hooks/pre-push, confirmed it correctly fires and fails when
targeting main with no tag, and is silent otherwise.

ADR: 0014
Refs: #87

docs/adr/0014-vale-prefilter-ships-from-the-plugin.md

@@ -97,3 +97,13 @@ doesn't wonder if it was overlooked.
   `SKILL.md`-shaped, and only skill-audit's `.vale.ini` has the matching glob section.
 - The first `vX.Y.Z` tag is cut once this change and its tests pass, giving external
   `.pre-commit-hooks.yaml` consumers something to pin.
+- **Cutting the tag is not left to memory.** `scripts/check-release-needed.sh`, wired at
+  `pre-push`, hard-fails — but only when `PRE_COMMIT_REMOTE_BRANCH` (set by pre-commit's
+  `hook-impl` for pre-push hooks) is `refs/heads/main` — if any path `.pre-commit-hooks.yaml`
+  exposes changed since the last tag reachable from `HEAD`. It is a silent no-op on every other
+  branch: hard-failing on feature-branch pushes mid-review would force a premature tag on a
+  commit that might not survive a squash-merge, the exact problem `repo: local` (above) already
+  avoids for this repo's own dev-time gate. A tag not existing at all is also a hard fail on
+  `main`, covering the very first release. This is deterministic tooling, not a standing
+  instruction to remember — consistent with `check-manifests.sh`/`check-vale-style-sync.sh`
+  already using the same pre-push, main-agnostic-elsewhere pattern.