feat(checks): a project with a stack says whether its own gates are armed

[Tradebaas]

What changed and why

Nothing in checks/ knows anything about a product's code. The gates prove documents, budgets,
traces and secrets, and every one of them stays green on a repo whose TypeScript does not
compile. The tools that do know are the ecosystem's own, and stack section 3 wires them into
CI when the stack is chosen, replacing the commented placeholder stage the workflow ships with.

Until that happens there was a window nobody watched. enforcement.mjs reports CI as armed the
moment any workflow file exists, so a project could choose a stack, write its standards file,
pass all 21 Groundwork gates, read "CI armed" in its own report, and have not one line of its
own code checked by anything. Same family as the two defects fixed earlier today: a gate that
is off without anyone deciding it should be.

The new stack-gates gate fires on exactly that window: a standards file that is not the
cross-stack floor, plus a workflow still carrying commented-out stack gates.

What it deliberately does not do is name the tools it expects. A list of blessed commands
per ecosystem is an allowance list, and this repo has already reasoned once that an allowance
list is the thing that rots. So the mechanical half is "the placeholders were dealt with", and
proving the wired gates actually bite stays where stack section 3 puts it: introduce a
violation, watch it fail, revert. That limit is written into the module, not left implied.

Three cases stay quiet on purpose, each with its own test: a fresh copy that has not picked a
stack (otherwise every new project starts on a red gate), GLOBAL.md on its own, and a project
whose CI lives on another host, which stack allows and enforcement.mjs already reports on.

It lands in its own file because adding it to check.mjs took that file to 527 lines against
its own 500-line cap. Splitting by responsibility is what PR #61 did for the same reason, so the
suite mirrors the source: check-stack.mjs + check-stack.test.mjs, composed into the one
registry beside the code and trace families. ci.yml and the drill's suite list gain the new
suite; the drill's comment said "the five suites" while listing seven, corrected in passing.

Verified by

• Red first, both directions. The expectFail proves the gate fires on the window. Then the
  gate body was temporarily replaced with return; and the suite went red
  (expected check "stack-gates" to fail, got: []), proving the test catches a dead gate, and
  restored.
• All nine suites green: check 78, check-code 34, check-trace 48, check-stack 5,
  progress 25, links 19, cockpit-path 11, cockpit 21, drill 11.
• node checks/check.mjs green, after two gates of this repo turned red on the change and
  were fixed at the cause, not weakened: code-file-cap at 527 lines (fixed by the split) and
  explainer-stats at 21 vs 22 gates (fixed on the page). Both were caught by the gates rather
  than by me.
• node checks/drill.mjs --require-walk PASSED, now reporting 8 suites in the copy. It
  failed twice first, correctly: the new files were untracked, and then staged but uncommitted,
  and the drill archives a commit. That is the drill proving a file that does not ship does not
  reach a copy.
• Terminal safety checked, not assumed. The message quotes back a filename a document chose,
  so a fixture with an escape sequence in the stack filename was run through the gate: the name
  is quoted and the control characters are gone, inheriting forTerminal from the shared fail.

Not verifiable here: the gate has never run on a real product, because Groundwork has no stack.
That is the same N=1 limit the gate itself is about, and it is why the five fixture cases carry
the proof instead.