The workspace DELETE route only checked the deleter's own workspace
count before allowing deletion, not the workspace being deleted. An
org admin with implicit admin access to every org workspace could
delete another member's only workspace, leaving them with zero
workspaces.

archiveWorkspace now checks, inside the same transaction as the
archive, whether any member of the workspace being deleted would be
left with zero active workspaces, and blocks if so. The ban flow
(disableUserResources) opts out via force: true since it must fully
disable a banned user's workspaces regardless of other members.

…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.

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).