[Reliability] Make launch acceptance and cleanup atomic

[fettpl]

Summary

Makes launch admission, cancellation, and cleanup atomic by assigning every accepted launch an immutable attempt identity and requiring all state transitions to compare that identity.

Closes #226

Dependency

Depends on #244. The issue-specific implementation is a seven-file controller delta on top of that release-gating prerequisite.

Root cause

Launch admission used a check-then-set sequence: it observed idle state, awaited process discovery, and only then reserved the launch. Ownership was keyed by recipe ID, so a repeated attempt could replace cancellation state and stale cleanup could clear or cancel a successor.

Solution design

• Reserve launch admission synchronously before the first await with an immutable UUID attempt identity.
• Return deterministic 409 conflicts for concurrent same- and different-recipe launches.
• Require cancellation to name the exact active attempt and expose that token in controller status.
• Carry the attempt through coordinator completion, cancellation, cleanup, and compare-by-token release.
• Report matched cancellation only after cleanup succeeds; normal ready or already-running completion returns 409.
• Retain active ownership and the cleanup error after failed cleanup so only the owner can retry.
• Reject eviction while a launch attempt is active.
• Coordinate route completion and cancellation with an Effect Deferred so stale finalization cannot release a successor.

Acceptance criteria

• There is no await between successful admission and reservation.
• Concurrent same- and different-recipe requests admit exactly one attempt.
• A stale release or cancellation token cannot clear or abort a successor.
• Cancellation targets the exact active attempt and reports success only after cleanup wins.
• Failed cleanup retains attempt ownership for an exact-token retry.
• Eviction cannot race an active launch attempt.
• Race coverage uses deterministic Effect deferred barriers rather than timing assumptions.

Validation

• Reviewed and published exact head: f716b5d3413a365e7a3eeb775fdb918cf75b2a5d.
• Focused launch-acceptance suite: 5 tests, 38 assertions, 0 failures.
• Controller typecheck, lint, dependency, duplicate, dead-code, and standards gates: passed.
• npm --prefix frontend run check:quality: passed.
• npm run check: passed, including contracts, structure, frontend production build, and controller gates.
• Normal pre-push hook: passed again while publishing the exact reviewed head.
• Independent P0/P1 review of the exact head: approved with no findings.
• Worktree is clean and git diff --check passes.

Current main does not define npm run test:integration or a generic npm --prefix frontend run test script, so those unavailable commands are not represented as passing.

UI changes

None. The issue-specific delta is controller-only; no additional desktop rebuild is required beyond the already validated stacked prerequisite.

Risks and rollout

• Clients cancelling an in-flight launch must supply the exact attempt_id; stale or unscoped cancellation is rejected rather than risking a successor.
• This preserves the release 2.0 single-launch model and does not add queueing or multi-model scheduling.
• Merge [CI/CD] Gate every release on the exact commit that passed CI #244 first, then refresh this branch onto main if GitHub does not remove the stacked prerequisite automatically.

[fettpl]

@0xSero This ready/non-draft fork PR now points to independently reviewed exact head f716b5d. Its focused launch suite, controller gates, full repository check, and intact pre-push quality/build hook passed. Current-head workflows are waiting at GitHub’s fork approval gate: CI run 29731261530 and Security run 29731261303. Please approve these runs when convenient.