Extend the MCP-only 'release due' watcher to engine/miner/ui-kit

[JSONbored]

Context

Investigated during a 2026-07-24 release-pipeline review (following up on #8525's already-fixed
tag-at-wrong-commit bug and #8519's stale-but-resolved MCP tracking issue, both closed today).

mcp-release-watch.yml (daily cron) + scripts/check-mcp-release-due.ts + scripts/mcp-release-core.ts
give MCP a real safety net: it opens/refreshes a tracking issue when unreleased commits pile up, and
auto-closes it (with a comment) once release-please catches up -- this exact auto-close behavior was
itself built to fix a prior incident (#6145: a stale "release due" issue stayed open after the actual
release had already shipped).

packages/loopover-engine, packages/loopover-miner, and packages/loopover-ui-kit have no
equivalent watcher. If release-please ever silently stops proposing a release PR for one of them (the
exact class of problem this mechanism exists to catch), there's currently no signal at all -- nothing
opens an issue, nothing pages anyone.

Why this isn't a quick fix

scripts/mcp-release-core.ts (394 lines) is heavily MCP-specific, not a thin parameterized core:

• Hardcoded DIRECT_MCP_PATHS, MCP-specific commit-scope filtering (EXCLUDED_SCOPES)
• MCP-compatibility-metadata-specific checklist items ("Update MCP compatibility metadata minimum
  supported and latest recommended versions to ...") that don't apply to the other three packages
• Hardcoded npm script names in its generated checklist: test:mcp-pack, changelog:check:mcp,
  test:release:mcp

None of those three scripts exist for engine or ui-kit today (only test:miner-pack exists, for
miner) -- checked directly against package.json. So this isn't just "parameterize the existing
script": it also needs the missing supporting npm scripts added per-package first.

Task

• Add test:{engine,ui-kit}-pack equivalents (mirroring test:miner-pack's shape) if a genuine
  pack-smoke-test doesn't already exist under a different name for those two packages.
• Extract mcp-release-core.ts's package-specific bits (paths, excluded scopes, checklist items,
  script names, tag prefix) into a per-package config object; keep the due-detection /
  issue-upsert / auto-close logic shared.
• Add a {engine,miner,ui-kit}-release-watch.yml per package (or one parameterized workflow with a
  matrix -- weigh against the shared-runner-pool concurrency concern from Epic: consolidate the '-coverage' bolt-on test-file family #8574's discussion; a
  single scheduled run iterating all three sequentially avoids adding concurrent runner load).
• Regression tests mirroring whatever check-mcp-release-due.ts's own test coverage already
  verifies (upsert/close logic, isReleaseWatchIssue marker matching) for the generalized version.

Not urgent -- release-please's normal automatic PR flow is the primary mechanism and has been reliable
for these three packages; this closes a monitoring gap, not a currently-active bug.

[linear-code]

JSO-5950