fix(web): retain Stop identity across session switches and native wakes

[627150795]

Problem

Closes #468.

Web Stop derives its target from a Web prompt trace. Switching from a running Session A to B and back clears that trace, so A stays running without a usable Stop handle. A native follow-up wake has no Web prompt trace at all and loses the same control.

Value

Users can stop the selected Session's actual running turn after switching Sessions, reloading the browser, or receiving a native wake.

Approach

Track the execution identity on its Pi runtime from agent_start through agent_settled, independently of Web prompt tracing. Retained runtimes keep their identity; native runs receive a unique handle. Retry and continuation starts within an unsettled run reuse that handle. Keep the existing Session/command/epoch guards and terminal-outcome requirement for accepting cancellation, and avoid retaining an abort operation when abort settles synchronously.

Validation

• Regression tests cover A → B → A, native starts, retained-runtime settlement, retry identity, stale and repeated handles, and synchronous abort settlement. They exercise production runtime methods with controlled Session events.
• node --test --experimental-strip-types tests/web/pi-runtime.test.ts tests/web/web-host.test.ts: 83 passed.
• Provider Playwright suite: 3 passed. A held provider response remains cancellable after A → B → A and reload; an old handle cannot cancel B or A's next turn. A real /cron in 30s native wake receives a handle and can be stopped through the browser.
• Browser tests use a local fake provider and isolated Pi directory. pi list in that directory reports only this source checkout. Screenshots were visually checked. Subagent/Workflow completion itself was not separately run; the Cron test exercises the shared native follow-up/trigger-turn entry path.
• bun run check and git diff --check: passed.
• bun run test on Windows / Node 24.14.0: 1,516 passed, 2 failed, 10 skipped. The failures were the existing git-info/process.test.ts 1-second process timeout and workflows/execute.e2e.test.ts detached-workflow settlement timeout, also seen on the audit baseline. The runner stopped before its later Windows serial and Vitest partitions. Full local suite success is not claimed.

Impact

• User-visible behavior: Stop remains available for the selected running Session across switching, reload, and native wakes.
• Model-visible context/tools: none.
• Runtime/lifecycle: execution identity follows its Pi runtime; cancellation remains scoped to one validated turn. Existing terminal settlement and admitted follow-up semantics are preserved.
• Persisted config/data: none. The browser test's package registration is confined to its temporary Pi directory.
• Compatibility/risk: the existing cancellation request shape is unchanged. This does not add global cancellation of background owners.

[tt-a1i]

Reviewed at 64c5ec8.

The implementation direction looks sound: execution identity is owned by the Pi runtime lifecycle rather than the originating Web prompt trace, retained runtimes preserve the current handle across session switches, and the existing session/command/epoch guards remain intact.

I am holding approval pending the acceptance evidence requested by #468. The browser coverage currently uses a cron wake, while the issue explicitly calls for a real Subagent or Workflow completion native wake and verification that the unique execution identity is reflected consistently in events, snapshots, the Composer Stop state, and the terminal outcome. The generic agent_start seam makes the implementation plausible, but that exact path is not yet demonstrated.

Local validation: bun run check passed; 83 focused pi-runtime/web-host tests passed. Hosted CI is green.