🤖 CoderWorkspacePool Share mode: optionally stop the workspace when a share is revoked #450

Problem

When the share policy no longer allows a share, the operator removes the Coder user from the workspace ACL and the claim reports ShareRevoked (#446). Coder also drops shares itself, for example when an admin tightens the organization's sharing setting (ShareRemoved). In both cases, Coder applies the removal only after the workspace restarts (Shared workspaces: "The workspace must be restarted for the user or group removal to take effect"). The operator does not restart or stop the workspace, so the user keeps access until someone does. A claimed workspace can run for a long time: a template with a default TTL of 0 has no autostop, and claims.idleTimeoutSeconds is opt-in.

Found by the Codex reviews of #446 (normal P1 and security P2): #446 (comment) and #446 (comment)

Current behavior (#446)

The ShareRevoked and ShareRemoved messages and the pool how-to say that the user keeps access until the workspace restarts or stops. They tell the admin to restart or stop the workspace in Coder, or to delete the claim, to end the access at once. This matches Coder's own unshare, which also leaves the restart to a person.

Option

An opt-in setting on the pool or the control plane: after a revocation, the member stops the workspace with the operator token, confirms the stop build, and only then reports the share as revoked. This needs:

1. A crash-safe state between the ACL removal and the confirmed stop, so a lost status write still leads to the stop.
2. Handling of an active build (cancel with expect_status, as the member's delete cleanup does).
3. A decision for ShareRemoved, where Coder or a person removed the share.
4. A Kind check in P9 that the user loses an open session.

It interrupts the claimant's session, so it stays opt-in. It changes plan 6.2 step 11, where a bound member only watches its workspace. Refs #153.

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: xhigh