fix(governance): let the hypatia baseline filter actually run (scan exit-on-findings under bash -e) (#464)

## Summary

Follow-up to **#455**. That PR wired `apply-baseline.sh` into
`validate-hypatia-baseline`, but the fix never actually ran:
`hypatia-cli.sh scan .` **exits non-zero by design whenever it finds
anything**, and the step runs under `bash -e`, so **errexit aborted the
step at the scan line — before the relativization + `apply-baseline.sh`
(the real gate) could run.**

This is also why the pre-#455 job was *always* red on every repo with
findings: its dead `jq` count never executed either. The scan's exit-1
killed the step every time.

**Caught by verifying end-to-end on neurophone#171**, where the job died
at:
```
[hypatia] scan complete: 18 findings >= medium (critical=3, high=9, medium=6); exit 1
##[error]Process completed with exit code 1.
```
…with **no** `apply-baseline.sh` output at all.

## The fix

```bash
HYPATIA_FORMAT=json "$HOME/hypatia/hypatia-cli.sh" scan . > hypatia-findings.raw.json || true
# never swallow a genuine scanner crash into a false pass:
if ! jq -e 'type == "array"' hypatia-findings.raw.json >/dev/null 2>&1; then
  echo "::error::hypatia scan did not produce a valid JSON findings array (scanner error, not a baseline result)"
  exit 1
fi
```

- **`|| true`** — tolerate the scan's by-design exit-on-findings so the
baseline filter runs and becomes the gate.
- **JSON-array guard** — a genuine scanner *crash* (non-array / empty
output) still fails loudly, so tolerating the exit code can't produce a
silent-green.

Both behaviours simulated locally under `bash -e`:
```
sim 1 (scan exits 1, valid output)  -> REACHED-FILTER   rc=0   ✓
sim 2 (scanner crash, non-array)    -> GUARD-FAIL        rc=1   ✓ (no silent-green)
```

## Heads-up for callers (separate, repo-side)

A **newer hypatia HEAD** reports more findings than when a repo's
`.hypatia-baseline.json` was written (neurophone: 18 now vs 14 when its
baseline was authored in #168). So after this lands, a caller may still
see its gate stay red on **genuinely-new** findings — that is the filter
working correctly. Resolution is per-repo: extend the baseline (or fix
at source), not here.

Draft pending CI + your review (edits the shared security gate). Same
opt-in-via-SHA-pin safety as #455.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_0172RBMz3qYjb1ttzD2i7RNh

---
_Generated by [Claude
Code](https://claude.ai/code/session_0172RBMz3qYjb1ttzD2i7RNh)_

Co-authored-by: Claude <noreply@anthropic.com>

Author: hyperpolymath

.github/workflows/governance-reusable.yml

@@ -128,7 +128,17 @@ jobs:
           BLOCKING_THRESHOLD: info
         run: |
           echo "Scanning repository: ${{ github.repository }} (checking baseline)"
-          HYPATIA_FORMAT=json "$HOME/hypatia/hypatia-cli.sh" scan . > hypatia-findings.raw.json
+          # hypatia's `scan` exits non-zero whenever it finds anything — that is
+          # by design, and under `bash -e` it would abort this step at this line,
+          # before the baseline filter (the real gate) ever runs. Tolerate the
+          # scan's own exit code…
+          HYPATIA_FORMAT=json "$HOME/hypatia/hypatia-cli.sh" scan . > hypatia-findings.raw.json || true
+          # …but never swallow a genuine scanner crash into a false pass: require a
+          # valid JSON array before trusting the output as "the findings".
+          if ! jq -e 'type == "array"' hypatia-findings.raw.json >/dev/null 2>&1; then
+            echo "::error::hypatia scan did not produce a valid JSON findings array (scanner error, not a baseline result)"
+            exit 1
+          fi
 
           # Relativize finding paths before matching. Hypatia's honest_completion
           # and code_safety modules emit ABSOLUTE host paths in `.file`