fix(ci): source-pin scanner cache in governance baseline job too

The `validate-hypatia-baseline` job carried the same keyless
`hypatia-scanner-v2-${{ runner.os }}-build` cache + `if [ ! -d ]` /
`if [ ! -x ]` guards as the standalone scan workflow, so baseline
validation ran against whatever scanner was first cached — a stale
ruleset that never picked up rule changes. Apply the same source-pinned
key (resolve hypatia HEAD via git ls-remote, fold the SHA into the key)
so the scanner rebuilds when hypatia main advances.

Note: this makes the baseline job use the *current* scanner; it does not
by itself resolve the separate pre-existing self-scan finding count on
standards (tracked separately).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017wGTeLwiBGJ5rETC3QT4Pm

Author: claude

.github/workflows/governance-reusable.yml

@@ -63,14 +63,35 @@ jobs:
           elixir-version: '1.19.4'
           otp-version: '28.3'
 
+      - name: Resolve Hypatia HEAD commit
+        id: hypatia-rev
+        run: |
+          # Pin the cache to the *current* Hypatia main tip. Resolved before the
+          # cache step because cache restore happens before the clone, so the key
+          # cannot hash a not-yet-cloned tree — it must hash the remote ref.
+          sha=$(git ls-remote https://github.com/hyperpolymath/hypatia.git HEAD | cut -f1)
+          if [ -z "$sha" ]; then
+            echo "ERROR: could not resolve hypatia HEAD via git ls-remote" >&2
+            exit 1
+          fi
+          echo "sha=$sha" >> "$GITHUB_OUTPUT"
+          echo "Resolved hypatia HEAD: $sha"
+
       - name: Cache Hex/Mix and Scanner Build
         uses: actions/cache@27d5ce7f107fe9357f9df03efb73ab90386fccae # v5.0.5
         with:
           path: |
             ~/.mix
             ~/.hex
             ~/hypatia
-          key: hypatia-scanner-v2-${{ runner.os }}-build
+          # Source-pinned key: when Hypatia main advances, the SHA changes, the
+          # cache misses, and the clone + escript build below re-run instead of
+          # restoring a stale binary. The old keyless `...-build` key meant the
+          # first scanner ever cached was reused forever, so baseline validation
+          # ran against a stale ruleset. No restore-keys on purpose — a partial
+          # restore would repopulate ~/hypatia and the guards below would skip
+          # the rebuild, reintroducing the staleness.
+          key: hypatia-scanner-v3-${{ runner.os }}-${{ steps.hypatia-rev.outputs.sha }}
 
       - name: Clone Hypatia
         run: |