fix(engine): require a gittensory-engine version bump on gate-decision logic changes and extend the parity scan to advisory.ts/gate-advisory.ts

[JSONbored]

Context

A maintainer review-stack × Autonomous Miner System (AMS) integration audit (2026-07-09) found that nothing ties a live gate-logic change to a required gittensory-engine version bump/republish, and the one mechanical drift check that exists is structurally blind to the actual hand-duplicated gate-decision engine pair.

Evidence

• .github/workflows/publish-engine.yml:15-21 — publishing @jsonbored/gittensory-engine is workflow_dispatch-only; nothing triggers it automatically on a gate-logic change.
• scripts/check-engine-parity.ts:11 — ENGINE_PARITY_AREAS = ["review", "settings", "signals"]. The actual hand-duplicated gate-decision engine pair — src/rules/advisory.ts (978 lines) vs. packages/gittensory-engine/src/advisory/gate-advisory.ts (644 lines), both implementing near-identical evaluateGateCheckCore/isConfiguredGateBlocker/buildPullRequestAdvisory logic — lives outside all three scanned directories, so the scanner structurally cannot discover it.
• scripts/check-engine-parity.ts:234-260 — checkMinerEngineVersionPinSync only string-diffs the pin file against package.json's declared version, never actual content/behavior.
• Issue feat(miner-selfimprove): engine-parity drift detector — flag when gittensory-engine diverges from src/ #4260 (closed 2026-07-09, the direct origin of check-engine-parity.ts) explicitly named ~15 specific file pairs to scan — none of which is advisory.ts/gate-advisory.ts — confirming this pair was deliberately left out of the original scope, not merely missed.

Why this matters for the Autonomous Miner System

This is safe today only because the live gate auto-deploys immediately on merge (Cloudflare Workers Builds), so MCP predictions — which run inside that same deployment — can't drift from it. It becomes a real risk the moment the still-open local iterate-loop orchestrator (#2333/#2334) starts self-reviewing against a locally-installed @jsonbored/gittensory-engine copy instead of round-tripping through MCP: there would be zero automated signal for how stale that installed copy is relative to main's actual gate-decision rule content.

Deliverables

• Extend ENGINE_PARITY_AREAS (or add a dedicated check) to cover the src/rules/advisory.ts ↔ packages/gittensory-engine/src/advisory/gate-advisory.ts pair specifically
• Add a CI gate that fails a PR touching gate-decision logic in either twin without a corresponding version bump to packages/gittensory-engine/package.json
• Consider whether publish-engine.yml should gain an automatic (or at least CI-prompted) trigger tied to a version bump on main, rather than relying solely on a maintainer remembering to workflow_dispatch
• Tests: a synthetic diff to one twin without a matching change/version-bump to the other fails the new check; a synthetic diff to both together passes

---

Surfaced by a maintainer review-stack × AMS integration audit (2026-07-09). Related: #4260 (the engine-parity drift detector this issue extends — its scope explicitly excluded this pair), #4257 (a heavier live-processors.ts-vs-predicted-gate.ts behavioral cross-check — a different, complementary mechanism to this issue's lighter mechanical version-bump gate).

[linear-code]

JSO-3355