mcp(plan-dag): collapse the duplicated plan-DAG state machine into @loopover/engine

[JSONbored]

Context

Split out of #9537, which delivered every other item on its list. buildPlanDag / validatePlanDag / nextReadySteps and the step state machine exist twice:

• src/services/plan-dag.ts — the Worker's copy, fully typed.
• packages/loopover-mcp/bin/loopover-mcp.ts:287-340 — a hand-duplicated, untyped copy, whose own comment explains why: "this file resolves @loopover/engine through the published package, whose export map does not surface it."

They are the same algorithm, and a fix to one silently misses the other. packages/loopover-miner/lib/plan-store.ts holds a third partial view (the persisted step statuses), now at least sharing one vocabulary after #9537 corrected PLAN_STEP_STATUSES.

Why it did not land in #9537

The correct shared home is @loopover/engine — this is pure, deterministic, dependency-free logic, which is exactly the engine's charter, and the contract package cannot take it (zod-only leaf). But packages/loopover-mcp depends on @loopover/engine at ^3.15.2 and resolves it from the registry when the CLI is installed. Adding an export therefore needs the engine published before a @loopover/mcp release can import it, and a merge that lands both at once leaves a window where a fresh npm i -g @loopover/mcp resolves an engine without the export and crashes at startup.

That release ordering is the whole problem, and it deserves to be got right on its own rather than as a footnote to a 102-tool migration.

Requirements

1. Move the implementation to packages/loopover-engine/src/services/plan-dag.ts and export it from the engine's root entry, preserving behavior exactly (src/services/plan-dag.ts's own tests must pass unchanged against the moved module).
2. src/services/plan-dag.ts becomes a re-export. No second implementation remains in the repo.
3. Bump @loopover/engine's version and packages/loopover-miner/expected-engine.version together, and widen @loopover/mcp's dependency range to the new minimum, in the SAME PR — with the release-ordering constraint stated in the PR body and confirmed against test:mcp-pack, which packs the CLI and must not resolve an engine lacking the export.
4. Delete the untyped copy in packages/loopover-mcp/bin/loopover-mcp.ts (buildPlanDag, validatePlanDag, nextReadySteps, isPlanStepDone, mapPlanStep, planView's helpers) and import from @loopover/engine; the three plan tools' behavior is pinned by the existing mcp-cli-* suites plus test/unit/plan-templates.test.ts and test/unit/issue-plan-decomposition.test.ts.
5. Full branch-counted patch coverage on anything that moves, per the house bar.

Non-goals

• Changing the plan-DAG algorithm, the tools' wire shapes, or the persisted plan-store schema. This is a relocation.

Deliverables

• One implementation, in @loopover/engine, re-exported by src/services/plan-dag.ts
• The packages/loopover-mcp duplicate deleted and importing from the engine
• Engine version bump + miner pin + @loopover/mcp dependency range updated together, release ordering stated
• test:mcp-pack green against the packed CLI

Expected outcome

grep -rn "function buildPlanDag" returns exactly one hit, and the stdio server's plan tools run the same code the Worker does.

References

Split from #9537 (requirement 6). The published-export constraint is the same one recorded in #6153.

[linear-code]

JSO-6607

[JSONbored]

Superseded — done inside #9537 / PR #9565 after all.

The blocker I filed this for turned out not to be one: both publish-engine.yml and publish-mcp.yml are workflow_dispatch-only, so nothing auto-publishes on merge and the operator publishes the engine before the CLI in the normal order. The engine takes a minor bump for the new export, with expected-engine.version and both consumers' dependency ranges moved to ^3.16.0 in the same commit, so a published CLI can never resolve an engine without it.

Moving it also turned up a third partial copy already living in the engine (plan-export.ts, plan-step-readiness.ts, plan-overall-status.ts). The moved module imports those rather than restating them and contributes only the mutating half of the state machine, which had no engine home.