fix(desktop): harden Windows managed-agent lifecycle recovery

[OpenSpek]

Status

Draft / help wanted — not merge-ready.

This contribution hardens Windows managed-agent Stop, shutdown, restore, and crash-recovery behavior. It is intentionally being posted for upstream collaboration rather than held locally for another open-ended repair cycle.

A final independent review pass found two unresolved safety concerns, documented below. Passing tests do not overrule those counterexamples.

What this changes

• Adds typed, versioned recovery authority scoped to an exact (agent, relay/workspace) pair.
• Fails closed when Windows PID/process-ownership evidence is missing, malformed, or contradictory.
• Preserves process, exit-status, Windows Job, receipt, pending-failure, retry, and recovery evidence across persistence failures.
• Keeps rejected restore admission observationally read-only.
• Adds durable recovery-sidecar validation, migration, reconciliation, transaction locking, and tombstone compaction.
• Extends Stop, poll/list, shutdown, startup restore, and managed-launcher lifecycle coverage.

Known review concerns

1. Shutdown diagnostics may broaden exact-pair uncertainty

shutdown.rs can append a shutdown diagnostic to canonical recovery detail through runtime_types.rs. A later reconciliation may treat the same exact key/PID with changed detail as conflicting evidence, escalate it into agent-wide quarantine, and block a clean sibling pair.

Help requested: separate ordinary diagnostic history from canonical recovery identity/provenance, or otherwise ensure diagnostic enrichment cannot manufacture conflicting ownership evidence.

2. Some Stop/shutdown paths may retire Child/Job authority before the primary record commits

The shared synchronization path preserves the finalized runtime token through primary-record persistence, but explicit Stop, pair-runtime Stop, and shutdown paths still appear able to clear/retire finalized Child/Job authority before the caller's managed-agent record save succeeds.

Help requested: decide where the durable commit barrier belongs in the Stop API so a failed primary-record save retains equivalent retry authority and cannot publish a terminal state prematurely.

Validation

Exact current-main port commit: 0262a73ac2f419aa8cdf04a6a284594437ca888b

Windows MSVC (rustc 1.95.0):

• Full desktop Rust suite: 2,071 passed, 0 failed, 10 ignored
• cargo check --workspace --all-targets --all-features: passed
• cargo fmt --check: passed
• git diff --check: passed
• Repository file-size gate: passed
• Current upstream merge/port: no conflicts

Linux-target validation was not run because this test host has only the Windows MSVC standard library installed.

Coordination check

I searched open and recent Buzz PRs before publication. The closest items were:

• Harden managed agent liveness and response visibility #3179 — managed-agent liveness/SLA status; overlaps runtime status files but not durable Stop/recovery authority.
• fix(acp): retire sessions safely and preserve terminal receipts #3446 — ACP session retirement and terminal receipts; a different session lifecycle.
• fix(desktop): detach managed agents from the controlling terminal (setsid) #2321 — Unix TTY/process-group detachment; not Windows managed-agent recovery.

No existing PR appeared to implement or clearly supersede this exact Windows recovery-authority work.

Review request

Windows, Rust lifecycle, and persistence reviewers: please help resolve or challenge the two commit-barrier/reconciliation concerns above. Architectural guidance or focused follow-up commits are welcome. This draft should remain non-merge-ready until those concerns are resolved or maintainers explicitly determine that the current behavior is acceptable.