ci: track the spec's HEAD — the app conforms to the living spec

Design change, at the maintainer's direction: the gate now checks out
feedpak-spec at HEAD instead of a pinned SHA. .feedpak-spec-ref, its
40-char validation step, and the pin-bump machinery are gone.

Rationale: it is vital that the app conforms to the spec — the current
spec, not a snapshot. The pin bought determinism at the cost of a
maintenance loop (bump PRs, a PAT, weekly latency) and a window where the
gate verified against a stale spec. Tracking HEAD makes the dev flow fully
self-serve with zero upkeep: gated PR -> FEP -> spec merge -> re-run
checks -> green. Nothing to bump.

The trade-off is accepted with eyes open, and the docs state it: the
normal FEP is additive and can only loosen the gate, so it cannot redden
anyone's PR. Only a breaking spec change (rare, deliberate, MAJOR per the
spec's compatibility policy) turns PRs red repo-wide — which is the
correct org-wide signal that the app is out of conformance. The CI job
logs the spec SHA each run verified against, so any red run is
reproducible.

Failure messages now also say why it matters beyond the one PR (also at
the maintainer's direction): non-conformance that lands shows up as red CI
on every teammate's PR until it is resolved, and only its author can clear
it — the FEP route keeps everyone else unblocked. Tone softened throughout
(the exceptions-file header now explains rather than shouts).

Signed-off-by: topkoa <topkoa@gmail.com>

tools/check_spec_conformance.py

@@ -87,10 +87,14 @@ EXCEPTIONS_FILE = REPO / "feedpak-spec-exceptions.yml"
 # the spec's own governance says "a change is not part of the format until it
 # lands here", and the FEP process is how it lands.
 FEP = (
-    "A new manifest key must go through the feedpak Enhancement Proposal process "
+    "New manifest keys go through the feedpak Enhancement Proposal process "
     "(https://github.com/got-feedback/feedpak-spec/blob/main/CONTRIBUTING.md): land a PR on "
     "feedpak-spec that updates the normative spec, the JSON Schemas, an example, and the "
-    "changelog together — then bump .feedpak-spec-ref to the merged SHA in this PR."
+    "changelog together — then re-run this PR's checks; the gate verifies against the "
+    "spec's HEAD, so once your key is in the spec, this PR goes green. It matters beyond "
+    "this PR: the whole repo is checked against the living spec, so non-conformance that "
+    "slips in shows up as red CI on every teammate's PR until it's resolved — sorting it "
+    "out here keeps everyone else unblocked."
 )
 
 
@@ -254,8 +258,8 @@ def check_allowlist_closed(baseline: Path | None, bootstrap: bool) -> bool:
 
     for key in added:
         _fail(
-            f"{EXCEPTIONS_FILE.name}: this PR ADDS an exception for '{key}'. The allowlist is "
-            f"closed — it grandfathers keys that predate this gate and may only shrink. {FEP}"
+            f"{EXCEPTIONS_FILE.name}: this PR adds an exception for '{key}', and the allowlist "
+            f"can't take new entries — it only grandfathers keys that predate the gate. {FEP}"
         )
     if removed:
         print(f"  allowlist shrank (debt paid down): {', '.join(removed)}")
@@ -458,7 +462,7 @@ def main() -> int:
         "--spec",
         required=True,
         type=Path,
-        help="path to a feedpak-spec checkout (CI pins the SHA in .feedpak-spec-ref)",
+        help="path to a feedpak-spec checkout (CI checks out the spec repo's HEAD)",
     )
     ap.add_argument(
         "--baseline-exceptions",