docs: define 2.0.0 operator-fleet roadmap

[jason-allen-oneal]

Problem

Define the next major product direction as a multi-machine, multi-tenant operator control plane. Current release work repairs 1.2.0; this roadmap targets 2.0.0 and does not introduce an intermediate 1.2.1 release.

Implementation

• Add docs/v2.0.0-roadmap.md with the product objective, current-source baseline, controller/cell responsibilities, nine dependency-ordered milestones, ownership roles, and measurable exit evidence.
• Define tenant-isolated native remote execution, adapter enforcement tiers, direct peer interoperability, durable job correctness, lifecycle, quotas, and exact-artifact release gates.
• Require a three-cell/two-machine/two-tenant pilot and a direct repaired-1.2.0-to-2.0 compatibility, migration, and recovery plan.
• Link the roadmap from docs/README.md and mark docs/post-1.1-roadmap.md as historical context.

All implementation milestones remain planned. The roadmap does not claim fleet functionality is shipped or authorize deployment.

Compatibility impact

Planning documentation only; no stable or experimental interface changes. The roadmap requires a versioned 2.0 compatibility inventory, preserves the local workflow, and keeps upgrading separate from enabling fleet capabilities.

State migration impact

None. No runtime state, configuration, database schema, package version, release artifact, or tag changed. Future migrations have explicit backup, failure-recovery, and exact-artifact qualification gates in the roadmap.

Security impact

No executable boundary changes. The plan preserves existing hosted-mode restrictions, requires tenant-owned isolated execution and destination-side admission, and distinguishes application separation from enforceable isolation. It does not claim universal exactly-once effects, external rollback, or protection from a malicious infrastructure administrator.

Documentation impact

• Documentation updated
• Documentation not required

Documentation details: docs/v2.0.0-roadmap.md, docs/README.md, and docs/post-1.1-roadmap.md.

Validation

• Relevant unit and integration tests
• Compatibility and security boundary tests where behavior changed
• Cross-platform impact considered
• No unrelated formatting churn

Documentation-only change; runtime, integration, and boundary tests were not run because no behavior changed.

• node scripts/ci/run.ts format — passed.
• git diff --check and staged diff whitespace check — passed.
• One-off Markdown validation — all 75 relative links in the three changed files resolve; no stale roadmap filenames or R130 milestone identifiers; R200-00 through R200-08 appear in order.
• Independent internal architecture and tenant-boundary reviews — approved after clarifying pilot topology, minimum adapter tier, replay retention, compatibility, and release scope. These are planning reviews, not GitHub code-owner approvals or runtime validation.

CI status after opening

Documentation impact, Conventional title, workflow lint, dependency review/audit, and secret scanning passed. Quality/package jobs stop at the unchanged pnpm release:preflight version guard before tests or packaging: development HEAD is ahead of published v1.2.0; bump the package version before building.

The planning base and local v1.2.0 tag both resolve to 4f0f27bd3cc77fb926810865185e2bfdf66161cf; the documentation commit is 02bd0a983af1471a2cdf221b1e421aa15e419abd. This PR changes no package version, release guard, or workflow. It remains a draft pending separate handling of that repository-wide version rule; the roadmap request does not justify changing the ongoing 1.2.0 release repair.

Evidence: https://github.com/BlueDot-IT/Odinn-Forge/actions/runs/33940998707/job/101238278098 and https://github.com/BlueDot-IT/Odinn-Forge/actions/runs/33940998706/job/101238277884.

Rollback

Revert this documentation commit. No application or persistent-state rollback is required. The 1.2.0 release-repair work is untouched.