fix(managed-agent): the cancellation takeover never finishes against a replacement Broker #13171

What happened?

The cancellation half of the Hosted Turn takeover added in #13083 cannot finish once the Turn's owner has changed. That half is the coordinator's passive takeover load followed by POST /session/:id/managed-runtime/cancel.

The replacement owner's Broker answers execution status and release only for a Runtime Session it has adopted, and the passive load never adopts one. So the Turn stays CANCELLING and the coordinator retries forever.

I measured this on the packaged stack:

• Spring fat jar, dist/cli.js Hosted Harness;
• Runtime Broker with durable local workers;
• MySQL, on Linux.

It reproduces at 7ae1fa05, the last head of #13083. That head is identical, on the PR's 36 files, to the squash 728c13de now on main. It also reproduces at the earlier head b4e9d71b. Details are in round 4 of the real-environment verification.

A lost cancel reply makes no difference, because the cancel route is never reached (in-flight) or never succeeds (settled).

Why:

• recoverHostedRuntimeTurn with passive: true calls broker.status() without a broker.acquire() (packages/cli/src/serve/hosted-runtime-recovery.ts, passive branch).
• For a non-terminal execution, RuntimeBrokerService.getExecution goes through requireReadySession, which needs the Runtime Session to be active in this Broker process.
• A release of a session the Broker never adopted is refused with runtime_reconciliation_required. This is the same refusal that was behind F2 in round 1 of feat(managed-agent): Hosted Turn takeover and G1 failover E2E #13083.
• The unit suites stub status and release to succeed without an acquire. reports a parked execution passively and cancels the turn (hosted-harness-session.test.ts) even asserts expect(acquireSpy).not.toHaveBeenCalled(). So the tests encode a Broker contract that the real Broker does not offer after an owner change.

Reachability. Today the public API cannot put a Workspace Turn into CANCELLING: ManagedAgentStore.insertCancelCommand refuses Workspace Sessions with 409 workspace_unavailable. The #13083 design also says the cancellation takeover "is implemented for contract completeness but has no E2E mode". The verification reached the path by applying the store's own cancel transition (status = 'CANCELLING') after owner A died, then starting owner B. The path becomes live as soon as Workspace cancel is opened.

What did you expect to happen?

The coordinator's cancellation takeover should settle the Turn as cancelled:

• parked executions are stopped, or confirmed settled, without any dispatch;
• the Workspace lease is released, so another Session can use the Workspace;
• a replayed cancel is answered at its admission watermark.

Client information

Anything else we need to know?

Candidate fix: candidate-r4.patch, about 30 lines in hosted-runtime-recovery.ts.

• When a passive load has Runtime items, it acquires the Runtime Session first. Acquiring dispatches nothing.
• If the acquire or a status read fails, it hands the lease back.
• It flips the acquireSpy assertion above and adds an acquire stub to the three passive recovery tests.

On the same rig, with the candidate:

• All four cases end turn.cancelled, in 1.6 to 4.0 s. The cases are in-flight and settled, each with and without a lost cancel reply.
• In flight, the tool never runs, and undo has nothing to restore.
• The lease is released, and a second Session on the same Workspace then runs.
• A lost cancel reply is replayed at the same watermark (13 → 13, 18 → 18).
• The drive path is unchanged: two-tool takeovers complete, and the feat(managed-agent): Hosted Turn takeover and G1 failover E2E #13083 runner passes 3/3 in both modes.
• The changed CLI test files pass.
• It applies cleanly to main at 728c13de.

The candidate relies on the Broker being able to adopt the dead owner's binding. That works with the durable local-process provisioner, which the takeover modes already require. With the default provisioner the acquire itself cannot adopt; that Broker-side loop is #13040.

The alternative is a Broker-side change: answer status from the durable record, and accept the release of a session the Broker has not adopted.

Evidence: the rig, raw results and Harness logs (Broker 404/503 lines) are in pr13083/r4/. The scenarios are results/s2/{h7,h8,h8c}-*db-cancel*, and the driver is harness/rig/s2-takeover.ts with faults db-cancel and db-cancel-drop-reply.

Related: #13083, #13040, #12380.