…te guard

Address two review findings on the stranded-member check:

- The check only counted a member's explicit permission rows, so an
  org admin whose only explicit row was on the workspace being deleted
  could be wrongly reported as stranded even though they still have
  access to every other workspace in their org. Now reuses
  listAccessibleWorkspaceRowsForUser (explicit rows + org-admin-derived
  access) instead of a raw permission count, parameterized with an
  executor so it can run against the same tx.

- Two concurrent deletions of different workspaces shared by the same
  sole member could each read a pre-deletion count, both conclude the
  member isn't stranded, and together leave them with zero workspaces.
  The archive transaction now runs under serializable isolation (skipped
  when force is set, since that path never runs the check) so Postgres
  detects the write skew and aborts one transaction instead.

…ocking deletion

Blocking deletion when it would strand a member was the wrong UX: an
org admin doing legitimate cleanup would be stopped because some
unrelated, possibly-inactive member happened to have this as their
only workspace.

archiveWorkspace now always allows the deletion and instead
auto-provisions a personal fallback workspace, atomically in the same
transaction, for any member who would otherwise be left with zero
active workspaces. This guarantees the invariant holds regardless of
which route/link/client the affected member's next request comes
through, unlike the pre-existing client-side "no workspaces" recovery
which only covers the generic /workspace redirect page.

Extracted the workspace-creation write (insert workspace + owner
permission row + default workflow) out of the POST /api/workspaces
route into a shared lib/workspaces/create.ts so both the route and
the archival safety net use the same logic, parameterized by an
optional executor so it can run inside an existing transaction.

The ban flow (disableUserResources) keeps force: true, now meaning
"skip stranded-member handling entirely" — a banned user's owned
workspaces must still be fully disabled, and the banned user
specifically shouldn't be handed a fresh workspace as a side effect.

…workspaces

Normal workspace creation gets its own WORKSPACE_CREATED audit row;
the auto-provisioned fallback for a stranded member didn't, making it
only discoverable indirectly via the deletion's audit metadata.

archiveWorkspace now accepts an optional actor (from the deleting
admin's session) and records a WORKSPACE_CREATED audit entry per
fallback workspace it provisions, attributing the action to the admin
who triggered the deletion.

…ioning to opt-in

Per multi-angle simplify/altitude review of the auto-provisioning fix:

- archiveWorkspace's stranded-member handling is now opt-in
  (provisionFallbackForStrandedMembers, default off) instead of opt-out
  (force). A future caller of archiveWorkspace that doesn't know about
  this feature now gets the safe default (no side-effect workspace
  creation) rather than having to remember to pass force: true. Kept
  the logic inside archiveWorkspace's single transaction rather than
  splitting into two composable functions, since that would either
  reintroduce the TOCTOU race (separate transactions) or require
  threading an external tx through archiveWorkspace (bigger, riskier
  change for uncertain benefit).
- provisionedWorkspaceUserIds is now returned from the transaction
  callback instead of mutated via an outer `let`.
- Deduplicated CreateWorkspaceParams in app/api/workspaces/route.ts —
  now Omit<CreateWorkspaceRecordParams, 'executor'> instead of a
  hand-copied interface that could drift from the shared type.
- Added a comment at the createWorkspaceRecord call site in
  archiveWorkspace noting it intentionally bypasses
  getWorkspaceCreationPolicy (system-provisioned safety net, not user
  self-service).
- Renamed a colliding local test helper (createTx used for two
  different mock shapes in adjacent lib/workspaces test files).

disableUserResources (ban flow) no longer needs a flag at all — the
default now matches its existing behavior.

…jacent assertions

The previous commit's `if (!options.provisionFallbackForStrandedMembers) { return [] }`
returned from the ENTIRE transaction callback, not just the stranded-member
check — silently skipping every archival write (workspace.archivedAt,
apiKey deletion, mcpServers, workflowSchedule, etc.) whenever the flag
wasn't set. That's every caller except the interactive DELETE route,
including the ban flow: banning a user would report `{ archived: true }`
while leaving the workspace and all its resources fully live.

Also moves the audit-log call for auto-provisioned fallback workspaces
outside the transaction. recordAudit is fire-and-forget and doesn't
participate in the transaction, so recording it before the transaction
commits could leave a phantom audit entry pointing at a fallback
workspace that got rolled back (e.g. on a serialization failure).

Added a test asserting archival writes still run when the flag is off
(the exact gap that let the regression through undetected), and a test
proving no audit entry is recorded when the transaction subsequently
fails.

Both caught by Greptile review before merge.

…d by surrounding context

…s in stranding check

Two gaps found by Cursor review on the latest commit:

- findMembersStrandedByArchival only considered users with an explicit
  permissions row on the workspace being deleted. An org admin who
  accesses that workspace purely through their organization role (no
  permission row at all) was never evaluated as a stranding candidate,
  so they could be left with zero workspaces without getting a
  fallback. Now unions explicit permission holders with the
  organization's admins/owners (via the member table + ORG_ADMIN_ROLES)
  before running the same accessibility check on every candidate.

- A banned user who still holds a permissions row on someone else's
  workspace (they don't have to own it) would get a fresh fallback
  workspace if stranded by that workspace's deletion — even though
  banned users should never receive new resources. Now filters
  actively-banned userIds (via the existing getActivelyBannedUserIds
  helper, which also covers blocked emails/domains) out of the
  stranded list before provisioning.

Added tests for both: an org admin with no explicit permission row
gets provisioned when stranded, and an actively banned stranded member
does not get provisioned (and gets no audit entry).

…nnection mid-transaction

createWorkspaceRecord now only fires workspaceCreated telemetry when it commits
its own transaction; callers passing a nested executor (the fallback-provisioning
path) fire it themselves after their outer transaction commits, avoiding a phantom
event for a workspace that gets rolled back. getActivelyBannedUserIds now accepts
an executor so the stranded-member check runs the banned-user lookup against the
open transaction instead of borrowing a second pooled connection while the first
sits idle-in-transaction.

…ban flow; trim redundant comments

disableUserResources now opts into provisionFallbackForStrandedMembers.
Actively banned users are already excluded from receiving a fallback
(findMembersStrandedByArchival filters them out), so this only protects a
non-banned co-member of a banned owner's workspace from the same stranding
bug this PR fixes for interactive deletion — previously they had no safety
net at all.

Also trims several inline comments that only restated what the adjacent
assertion or test title already made clear, splitting a couple of
telemetry assertions into their own descriptively-named tests instead of
narrating them inline.