feat(scripts+ci): swap governance TS-allowlist check to AffineScript-compiled .deno.js (#311)

**Depends on: #310**

Second half of the seed-PR plan from #283: once the `.affine` source
actually compiles + runs (#310), wire the workflow at the
AffineScript-compiled output.

## Changes

1. **`scripts/check-ts-allowlist.deno.js`** (NEW, 344 lines)
- Generated by `affinescript compile --deno-esm` from the post-#310
`.affine` source. Self-contained Deno-ESM bundle: inlined runtime shims
for codegen-known externs (walkRecursive, regexMatch, readTextFile,
exit, consoleError) + the `split` / `ends_with` helpers. Auto-invokes
`await main()` at module load — same shape Deno runs the existing .ts
with.

2. **`.github/workflows/governance-reusable.yml:193`**
- `deno run ... check-ts-allowlist.ts` → `...
check-ts-allowlist.deno.js`
- Comment block explains the dual-target window: .ts kept for the
regression suite (`scripts/tests/check-ts-allowlist-test.sh`) and for
parallel-validation; retirement is a separate follow-up after the
validation window.

## Why ship the compiled artifact (vs compile-in-CI)

Compile-in-CI would require an AffineScript toolchain in the workflow
(OCaml + dune + affinescript repo as a dep). The compiler is
deterministic for this surface; committing the output keeps CI
provider-free and matches the precedent in
`affinescript/tests/codegen-deno/*.deno.js` (committed golden files).

Drift between source and committed output is the obvious risk. Follow-up
will add a `just check-ts-allowlist-drift` recipe (recompile + diff)
wired into a non-blocking CI lint.

## Verification

End-to-end runtime test of the compiled output (matches the runtime fix
in PR #310 commit b046787):

| fixture | exit | output |
|---|---|---|
| empty dir | 0 | success line |
| `src/Foo.ts` violation | 1 | error block + file list |
| `mod.ts` (filename ok) | 0 | success line |
| `scripts/x.ts` (dir ok) | 0 | success line |

## Test plan

- [ ] CI green on this branch — note AS scanner / Hypatia / SPARK
Theatre Gate may need to acknowledge the new committed `.deno.js` as a
generated artifact (ignore findings tagged as generated)
- [ ] `scripts/tests/check-ts-allowlist-test.sh` still passes against
the unchanged .ts archetype (no behavioural change to .ts)
- [ ] Caller repos using `governance-reusable.yml` show green "Check for
TypeScript" steps after merge

Refs #239 (umbrella TS→AffineScript), #241 (STEP 2 tail-batch-1).
Follow-up plan: add drift-detection lint, then a separate PR retires the
.ts archetype after the parallel-validation window.

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

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: hyperpolymath

.github/workflows/governance-reusable.yml

@@ -190,7 +190,14 @@ jobs:
         # `deno run` before the file-walker even starts — the script does not
         # import anything, so the lockfile is irrelevant to its execution.
         # See standards#294.
-        run: deno run --allow-read --no-lock .standards-checkout/scripts/check-ts-allowlist.ts
+        #
+        # Runs the AffineScript-compiled `.deno.js` (source of truth:
+        # `scripts/check-ts-allowlist.affine`). The .ts archetype is kept
+        # alongside for the regression suite (`scripts/tests/check-ts-
+        # allowlist-test.sh`) and for parallel-validation during the
+        # TS→AffineScript migration (standards#239 / #241). Retirement of
+        # the .ts is a separate follow-up after the dual-target window.
+        run: deno run --allow-read --no-lock .standards-checkout/scripts/check-ts-allowlist.deno.js
 
       # Shared escape hatch for the banned-language-file checks below.
       # Honours three exemption mechanisms (see

docs/EXEMPTION-MECHANISMS.adoc

@@ -137,8 +137,10 @@ across the estate. Three sub-layers:
 
 === 4a: Built-in path / filename allowlist
 
-Hard-coded in `scripts/check-ts-allowlist.ts`. Covers paths that are
-*always* exempt regardless of per-repo configuration:
+Hard-coded in `scripts/check-ts-allowlist.affine` (source of truth;
+compiled to `scripts/check-ts-allowlist.deno.js` which the workflow
+invokes). Covers paths that are *always* exempt regardless of per-repo
+configuration:
 
 * Directory segments: `bindings`, `tests`, `test`, `scripts`,
   `mcp-adapter`, `cli`, `vendor`, `examples`, `ffi`, `node_modules`,
@@ -230,11 +232,23 @@ sufficient. Most repos will pick one or the other.
   + new typed-infrastructure file. Owner picked the Layer-2.5 approach
   (standards#185) over the minimal regex-only fix (standards#183).
   This document seeds the doctrine.
+* AffineScript port (standards#283 seed, #310 compile/runtime fixes,
+  #311 workflow swap): `.ts` → `.affine` self-referential port under
+  the TS→AffineScript campaign (#239 / #241 STEP 2). The `.ts`
+  archetype is kept for the regression suite and parallel-validation;
+  the workflow now runs the compiled `.deno.js`. Retirement of the
+  `.ts` is a follow-up after the dual-target window.
 
 == Cross-references
 
 * `docs/HYPATIA-BASELINE-FORMAT.adoc` — the baseline file format.
 * `.machine_readable/hypatia-baseline.schema.json` — machine schema.
-* `scripts/check-ts-allowlist.ts` — the Deno detector behind Layer 4.
+* `scripts/check-ts-allowlist.affine` — the AffineScript source of
+  truth for the Layer 4 detector (since standards#283 / #310 / #311).
+* `scripts/check-ts-allowlist.deno.js` — the compiled artifact the
+  governance workflow runs.
+* `scripts/check-ts-allowlist.ts` — the Deno archetype, retained as the
+  regression-suite target (`scripts/tests/check-ts-allowlist-test.sh`)
+  and for parallel-validation during the TS→AS dual-target window.
 * `hyperpolymath/standards#????` — proposal that landed this consumer.
 * `hyperpolymath/hypatia` — the scanner that emits findings.