[ci]: coordinate host Docker cutover and runner-service isolation for daemon-first reuse

[svelderrainruiz]

Observed on 2026-03-21 from priority:delivery:host:signal and priority:jarvis:status after #1738 and #1740 merged.

Current host state:

• daemon-host-signal.status = desktop-backed
• daemon-host-signal.provider = desktop
• windowsDocker.context = desktop-linux
• windowsDocker.osType = linux
• wslDocker.isDockerDesktop = true
• multiple actions.runner.* services are still running on the host

Why this matters:

• the Linux daemon-first plane is intentionally blocked from reuse while WSL still resolves to Docker Desktop
• the Jarvis observer now reports daemonCutover.status = cutover-required
• runner-service activity means host isolation is not yet in the state expected for daemon-first reuse

Evidence:

• tests/results/_agent/runtime/daemon-host-signal.json
• tests/results/_agent/runtime/delivery-agent-host-isolation.json
• tests/results/_agent/runtime/jarvis-session-observer.json

Needed follow-up:

1. coordinate operator-host cleanup so the machine stops presenting as desktop-backed
2. stop or explicitly govern the still-running actions.runner.* services on this host
3. rerun priority:delivery:host:signal and priority:jarvis:status until the Linux daemon plane reports ready

This is a coordination / host-correctness follow-up, not a request to weaken the daemon guardrails.

[svelderrainruiz]

PR #1754 is fully green on hosted validation and has been handed to merge-sync.\n\nNote: the only local validation gap was jarvis-session-observer-schema.test.mjs in the clean lane because that checkout did not have �jv installed, but the hosted PR checks already covered the real dependency context and are green, so Sagan is treating this as a lane-local environment gap rather than a release blocker.

[svelderrainruiz]

Partial progress landed in #1754.

What changed:

• priority:jarvis:status now surfaces daemonCutover.requiredActions
• the Jarvis observer makes the missing host-cutover steps explicit instead of leaving daemon reuse ambiguous

Why this issue stays open:

• the host is still cutover-required for daemon-first Linux reuse
• runner-service isolation and Docker/WSL2 plane coordination still need real operator-safe implementation work

This issue now tracks the actual cutover/coordination work, not just the observer/reporting gap.

[svelderrainruiz]

Docs-only follow-up is now in PR #1762.

What it adds:

• explicit operator loop around daemon-host-signal.json
• explicit use of jarvis-session-observer.json and daemonCutover.requiredActions
• documented rerun sequence for host-signal and Jarvis status after operator coordination work

This keeps the host-cutover lane moving without pretending the next step is another daemon behavior change.

[svelderrainruiz]

Promoting to standing-priority.

Why this is next:

• docs: add jarvis daemon cutover operator loop #1762 is already in flight as the immediate docs-only daemon-cutover slice
• the merged observer/reporting work now makes the host cutover gap explicit instead of ambiguous
• this is the strongest current operational blocker once the Program: downstream/develop consumer proving rail between integration and release #1497 manifest-bridge slice has landed

Current focus under this standing issue:

• land docs: add jarvis daemon cutover operator loop #1762
• keep the daemon-first cutover lane explicit and operator-safe
• use the documented host-signal / Jarvis loop to drive the next non-docs step without regressing into guesswork