Keep ACP prompt runs executing after transport disconnects

**What problem would this solve?**
ACP prompt execution is currently scoped to the client connection. If a remote client's transport closes because of a network drop, laptop sleep, SSH tunnel interruption, or client exit, an in-flight turn is cancelled even though the server, session, and subprocesses remain healthy. This loses useful work and makes remote ACP and `goose roam` sessions fragile.

**What would a good outcome look like?**
Ordinary transport loss should not cancel an in-flight ACP prompt. The turn should continue running and persist its messages so a reconnecting client can load the completed session. Explicit cancellation and peer revocation must still stop the affected run, and disconnected interactive permission or elicitation waits must resolve without hanging.

**Possible approaches**
Detach prompt execution from connection-scoped tasks while retaining run ownership and cancellation in the shared active-run registry. Treat client notification failures as fail-soft after disconnect, fence revoked connections from starting or continuing runs, and independently resolve pending interactive requests when the transport terminates. Live reattachment to an actively streaming turn can remain out of scope.

**Additional context**
An implementation and verification details are already available in [PR #11668](https://github.com/aaif-goose/goose/pull/11668). The remaining review feedback concerns preserving the transport-termination fallback until permission or elicitation resolution has completed.

- [x] I have verified this does not duplicate an existing feature request

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).