test(miner-foundation): engine-parity regression runner (assert extracted === original)

[JSONbored]

Build the actual parity-runner test that the phase brief calls for: a suite that imports buildPredictedGateVerdict (and, as they land, the other extracted functions) from BOTH @jsonbored/gittensory-engine AND — via a temporarily-retained pre-extraction copy or a git-history snapshot — asserts the two produce byte-identical output on every fixture in the corpus from the sibling fixtures issue. Since the extraction issues in this phase already convert src/ call sites into re-export shims (so there is no longer a second live implementation to diff against post-extraction), this suite's actual mechanism is: snapshot the original src/rules/predicted-gate.ts output for every fixture BEFORE the shim conversion lands (as a committed golden-output JSON), then assert the shimmed src/ (which now just re-exports the engine) still produces those exact golden outputs. This makes drift in ANY future engine change immediately visible as a CI failure, not a silent divergence.

Deliverables

• test/contract/engine-parity.test.ts — for every fixture in test/fixtures/engine-parity/predicted-gate/, run it through buildPredictedGateVerdict (imported from src/rules/predicted-gate.ts, i.e. the public re-export surface the rest of the backend already uses) and assert deep-equality against a committed golden JSON.
• test/fixtures/engine-parity/predicted-gate/golden/ — one golden-output JSON per input fixture, generated once (by running the suite in a "record" mode or by hand) and committed.
• A npm run test:engine-parity script (or fold into test:ci directly) that runs this suite so CI catches drift on every PR, not just ones that happen to touch the engine package.
• Wire test:engine-parity into the root test:ci chain in package.json, alongside the existing test:mcp-pack/build:mcp steps, so a future engine-package change that silently changes output fails CI immediately.
• A doc comment at the top of the test file explaining the golden-snapshot mechanism and how to intentionally update goldens when a future PR deliberately changes gate behavior (vs. accidentally through refactor drift).

References

• src/rules/predicted-gate.ts — the byte-identity target; "byte-identical to the live merge/close gate" is the explicit phase requirement.
• test/fixtures/engine-parity/predicted-gate/ — created by the sibling fixture-corpus issue (must land first).
• package.json test:ci script (line 62) — existing chain pattern (... && npm run build:mcp && npm run test:mcp-pack && ...) to extend with the new parity check.
• Phase brief: "an engine-parity regression suite (assert extracted-engine output === original src/ output, byte-for-byte, on shared fixtures) so drift is caught immediately."

[linear-code]

JSO-2383