[ac-pplx]

Summary

Operators can now act on any organization from the console, through the admin
routes that #1302 and #1303 add and the actor_email field #1384 adds, and see
node and template state that #1307 already exposes. The console still works against an API without those PRs:
each new call detects the older answer and falls back to today's behaviour.

• API keys. The API keys page creates keys for any organization, choosing
  the "Acts as" user from that organization, with a preview of who the key
  will act as. For your own organization the choice is optional and the key
  acts as you, sending no user_id. For another organization it is
  required: api: let operators manage keys, terminals and snapshots across orgs #1302 now answers a key without user_id there with 400
  ("user_id is required for another organization's key") instead of picking
  the organization's oldest user, so the picker has no default and Create
  stays disabled until a user is chosen. Create waits while the
  organization's users load; after a failed read it says the key acts as
  you in your own organization, and asks for a retry in another. The
  created dialog names the organization and the key's user. A key whose user was deleted
  reads "No recorded user; acts as the organization's oldest user", which is
  what every release resolves it to. The page shows when each key was last
  used (SPACE and E2B-compatible API authentications, at most every five
  minutes; data-plane ECW envd calls are not recorded, and a key not used
  since the API began recording shows "Never") and, behind "Show revoked
  keys", revoked keys marked with when they were revoked. The organization
  page's key card shows the same columns.
• Terminal across organizations. A sandbox in another organization opens
  its terminal through the admin terminal route, and the card says so; your
  own organization's sandboxes keep the public route.
• Snapshots and rollback. Rollback is offered on the snapshots the
  sandbox's node keeps, the debug view's snapshots.inventory, and sends the
  row's snapshot_id as snapshot_name. The API passes that name to the
  node unchanged, and the node rolls back only to a snapshot directory it
  keeps, so the catalog's snap_<uuid> IDs, which main and earlier rounds
  of this PR sent, never rolled back. The sandbox page already reads the
  debug view every 20 s, so this list adds no request and no audit event. It
  leaves out the names sbx-mgr keeps for itself (d-stop-*,
  d-operation-*, GC staging), disables Rollback on rows the node does not
  report ready, and on every row while the sandbox is suspended ("Restore
  it first"); a full (f-*) snapshot's confirmation says the node must
  support snapshot restore. Your own organization's sandboxes roll back
  through the public :rollback, as on main; another organization's
  through :force-rollback with the public rollback body, once the admin
  snapshot list has answered for the sandbox. The catalog snapshot lists stay,
  for display only: your own organization's through the public routes,
  re-listed every 20 s on the sandbox page; another organization's through
  the admin list. api: let operators manage keys, terminals and snapshots across orgs #1302 writes an admin audit event for every admin list
  read, so that list is read when the panel or card opens and on its Refresh
  button, never on a timer; the card says when it was listed, and when more
  than the 1000 newest snapshots exist. A card or panel that found no admin
  list (an older release, or an old pod during a rollout) has a Refresh that
  asks again. The sandbox list's Snapshots panel has no Rollback and points to
  the sandbox page. After the 202, the console follows the rollback's
  operation and reports that it finished, failed with its reason, or is still
  running after two minutes, then reloads the page as after any action. Each
  rollback has its own notification; closing the view or showing another
  sandbox stops following it, and the notification says so. A refusal by the
  rollback gate (off by default) is remembered for that organization for the
  browser session, in every open view of that organization: Rollback is
  disabled with the API's reason, with a "Try again" link that applies to all
  of them. The sandbox page adds each catalog snapshot's storage (node-local,
  object store, both, none, with the node).
• Refusals in the API's words. Branding validation errors show inline on
  the organization page and mark the field. A user delete refused with a 409
  names the reason (owns sandboxes; deleted sandboxes kept until a time; owns
  archived sandboxes); the Users table no longer reads the organization's
  sandboxes to guess. A failed create names template_has_no_release or
  template_release_not_found with the API's message, also when snapshots
  were not requested. A user-delete 500 shows the API's message; the
  old-release hint replaces it only when the message is the generic
  "Internal server error".
• Node and template state. Nodes show cordon, node group and runtime
  installations on the list and the node page; absent fields show nothing.
  Each template row expands to its recent builds (state, content hash, error,
  status error, created time), read again on each of the page's refreshes
  while the row is expanded, and not while it is collapsed.
• Safer template operations. System builds send an Idempotency-Key per
  rebuild run and template. Building again resends it: api: close six admin API gaps the admin console works around #1303 answers with the
  first build when it recorded one (two tabs answered with the same job
  follow that one build, with no extra-build notice), and with a
  non-retryable 409 once the first request's outcome is unknown. On that 409 the rebuild panel shows the
  job it names, points to Template Releases and the template's builds, and
  offers "Start a new build", which sends a new key. The panel keeps listing
  each attempt a new build replaced, with the job the 409 named, and keeps its
  outcome unknown, since it may still publish a release. An answer that
  arrives late for a replaced attempt is listed on it as a note and never
  changes it, nor becomes the current build: a later refusal (a 403 after an
  authorization change, say) says nothing about the first request, since the
  API checks the request before it replays the key. Tag moves send expected_current_release_id from the tag
  holders read when the dialog opened, not from a later background refresh.
  OK first reads the template's releases again: if the typed tag moved since
  the dialog showed it, the dialog shows from where to where and asks again,
  advancing only that tag's precondition; otherwise it sends the move. A
  failed read sends nothing. OK sends one move
  at a time. A release that refuses the field gets one retry without it, and
  the operator is told the precondition was not checked.
• Sandbox page. A Quarantine card shows the active episode and the newest
  events, and "unknown" when the quarantine read failed; the environment
  shows names only, whichever shape the API sends.
• Operations. When a row carries actor_email (api: answer 409 for org deletes with users and duplicate emails, and name the actor on admin operations #1384), the console uses
  it and skips that row's user lookup.
• Dev warnings. Deprecated antd props (Space direction, Alert message,
  Input addonBefore, Statistic valueStyle, Modal maskClosable and
  destroyOnClose, modal.confirm autoFocusButton) and a Table rowKey
  index are replaced; behaviour is unchanged.

	Before	After
API keys
Branding refusal
User delete refusal
Rollback
List row snapshots
Snapshot storage
Terminal, another org
Nodes
Template builds
Create failure

Also:

Against an API without #1302 and #1303:

Validation

At this head, in ui/: npm ci && npm test && npx tsc --noEmit -p . && npm run build
(278 tests pass, type check clean, build succeeds). The branch is rebased
onto main with #1388's server-paged sandbox list; npx tsc --noEmit -p .
and npm test pass at every commit. Unit tests in ui/src/lib
cover each detection rule (missing route, unknown-field 422, page object or
array, absent fields), the snapshot route choice (own organization never
reads the audited admin list, and another organization's card does not list
on the page's reloads, which include its timer), the rollback targets (only
the node's inventory names, never a catalog snap_ ID; sbx-mgr's internal
names left out; ready and unpublished full snapshots offered, others
disabled; every row disabled while suspended; the body sent; the route for
each organization), following an operation to its end, the required key user for another
organization (Create disabled until one is chosen, no oldest-user text; an
own-organization key sends no user_id), an older release's 422 or 403 to
another organization's key read as the "only your own organization" notice, stopping when its
view closes, one notification per operation, and the rollback outcome text,
the rollback gate refusal and its per-organization store shared by every
subscribed view, the retag dialog's captured tag holders, its re-read on OK
(a tag moved since the page's last refresh warns and sends nothing; a failed
read sends nothing), advancing only the warned tag (two tags that both
moved) and one move per OK, the tag-precondition retry and 412 message, the
system build's closed key, "Start a new build" keeping the attempt it
replaced, a replaced attempt that a late refusal, failure or job leaves
unchanged and only noted, a replayed job taken as the build already
followed, two interleaved key generations, the builds panel reading only
while expanded, the key "acts as" choice and its texts, a cross-organization
key refusal limited to its organization, the quarantine status after a
failed read, the own-org check, and the user-delete messages.

Key user and the sandbox list's row actions, at this head, on a local Kind
stack (Direct substrate) running main with #1303, #1384 and #1302
cherry-picked and this branch's ui/ served by next dev, with one
synthetic tenant organization and the rollback gate on:

• Another organization's key: the dialog shows "Choose a user" with Create
  disabled; with a user chosen it sent user_id and the created dialog named
  that user. The key created a sandbox through the public API, and the admin
  API reported that sandbox's owner and the key's created_by as the chosen
  user. Before this change the console offered "The organization's oldest
  user (default)", sent no user_id, and the API answered 400 "user_id is
  required for another organization's key", shown as the error.
• Own-organization key: "You (default)", Create enabled, no user_id sent;
  the key acts as the signed-in operator (owner and created_by checked the
  same way).
• Paged sandbox list (?limit=50&cursor=): each row's Snaps switch queued
  :force-enable_snapshots, each row's panel listed the catalog (admin route
  for the tenant, public for the own organization, display only) and links to
  the sandbox page. There, Rollback on the node's d-1m-* snapshot sent
  :force-rollback (tenant) and :rollback (own organization), and both
  ended "Rolled back to d-1m-…". The terminal opened through the admin
  terminal route for the tenant and the public route for the own
  organization, and ran a command in each.

Key form	Before	After
Another organization
Own organization

Rollback and the retag re-read, at an earlier head, on a local Kind stack running
main with #1321, #1303, #1302 and #1384 cherry-picked and this branch's
ui/ as space-ui, with the rollback gate on for the managing organization
and one synthetic tenant organization:

• On the Direct substrate, with snapshots enabled on one sandbox in each
  organization, sbx-mgr's scheduler kept a d-1m-* snapshot for each. From
  the sandbox page, Rollback on that row sent
  {"snapshot_name":"d-1m-…","auto_restart":true} to the public :rollback
  (own organization) and to :force-rollback (the tenant), and both
  operations ended succeeded ("Rolled back to d-1m-…"). Listing the targets
  added no request: the page read the debug view on its own cadence, and the
  tenant's admin snapshot list once, when the card opened.
• With the tenant sandbox suspended, its node row's Rollback is disabled with
  the reason.
• The list row's panel shows the catalog snapshots with no Rollback.
• Retag: with a new tag typed in the dialog, the same tag was created through
  the API and OK pressed at once, before the page's list refreshed: OK sent
  only a releases read and showed the move; OK again read again and sent the
  move with the new holder as the precondition.
• On the Kubernetes substrate rollback did not succeed, for a reason outside
  the console: in both organizations, the first rollback attempt failed on
  the node ("sandbox host mutation or reset is in progress; retry") after
  stopping the VM. The operation's retry found the sandbox pod exited,
  recreated it on another node, and that node had no such snapshot. On Direct
  the same first-attempt failure occurred and the retry succeeded, since the
  sandbox stays on its node. This is a node or API defect for a separate
  issue.

The other screenshots above were taken before the review fixes of earlier
rounds. Those fixes were checked by the unit tests and the build only, not in a
browser or on Kind; that collapsing a sandbox row unmounts its snapshot
panel was checked once against the installed antd table in a throwaway
jsdom script, which is not committed; the rollback-refusal, rollback-queued
and rebuild-replayed screenshots no longer match the console and were
removed. The card's new Refresh, the replaced-attempt rows of the rebuild
panel and the API key "Try again" have no screenshot.

Before those review fixes, on a local Kind stack running main with #1321,
#1303 and #1302 cherry-picked (#1321 was on that stack; nothing here uses
it), the branch console was checked in a browser across two
synthetic tenant organizations: each action above, the rollback gate and
user-delete refusals, a real seed build listed and replayed by its key, and a
create against a digest with no release. The same stack was then redeployed
with main's API alone and each fallback checked. npm run dev on every
console route logged none of the listed warnings (one rowKey warning seen
in that sweep was removed afterwards; that last change was checked by tests
and the build, not in the browser again).

Not validated live: the quarantine card (rendered from a synthetic debug
section; no sandbox was quarantined), template_has_no_release and a 412 tag
precondition (unit tests only), rollback to a full (f-*) snapshot and to a
row the node does not report ready, the rollback gate refusal and the
older-release fallbacks at this head, the 405 fallback for template builds
on releases before #1307, and the admin audit rate of a sandbox page left
open (unit tests show the own organization's listing never reads the admin
list, and another organization's card does not list on the page's reloads).

Severity and risk

Severity: does not apply (operator console features and fallbacks).

Risk: for another organization's sandbox, the snapshot panels and terminal
call admin routes first. On an API without them, the console falls back on
the 404 the admin API's fallback answers ({"code": 404, ...}); a proxy that
rewrote that answer would show an error instead of falling back. Rollback is
sent to :force-rollback only when the admin snapshot list answered, because
older :force-rollback accepts the request and then fails the operation.
Rollback targets come from the node's last published inventory; a sandbox
that moved to another node since can list a name its new node lacks, which
the node refuses and the console reports as a failed rollback. The
gate refusal is recognized by its message ("rollback is not enabled"), since
it carries no reason code; a reworded refusal would show as an error, not be
remembered. Expanded template build histories re-read on each page refresh
(every 10 s while visible), which costs one builder status call per listed
build. Roll back by reverting the commits.

Rollout

The console can deploy before or after the API PRs. Older API releases get:
no "acts as" choice (422 named in the message); for another organization,
"this API version creates keys only for your own organization" after its
403, or after the 422 such a release answers first to the user_id another
organization's key always carries,
instead of the acts-as promise, for that organization only and until "Try
again" or another organization is picked; live keys only; own-org snapshots and
terminals only; a generic message for a refused user delete; and tag moves
without the precondition (with a warning).

While the API rolls out, pods of both versions answer the console. A
snapshot listing answered by a new pod can send a rollback to an old one,
which accepts :force-rollback and drops its body, so the operation fails:
the console shows that failure and its reason. During a mixed rollout the
first rollback attempt can fail this way; retry it once the rollout
finishes. A snapshot view answered by an old pod says the release cannot
list them; its Refresh asks again.

Stack

Merge after #1302, #1303 and #1384 (#1384 is stacked on #1303); the console
falls back cleanly on servers without them. #1302 and #1303/#1384 conflict in
IdentityAdminError::into_response, where #1302 builds the branding refusal
body ({error, field}) and #1303/#1384 build the user-delete refusal body
({error, reason, retained_until}); whichever merges second must keep both.
The console reads both shapes. #1302 and #1303 also conflict in the admin
sandbox create, where #1302 splits the organization check out of
create_sandbox_for_org and #1303 adds its requested_by argument; the
Kind stack above kept both. This branch needs #1302's current contract
(another organization's key requires user_id); against a #1302 that still
defaults to the oldest user, it only stops offering that default.

Not covered

• The create-key dialog's "Allowed APIs" default starts unchecked, as on
  main; unchanged here.
• Organization-delete and duplicate-email 409s (org_has_users,
  email_in_use) come from another PR; those flows already show any error's
  API message.

AI assistance: an AI agent (Claude Code) wrote the code, tests, validation
and this description.

[github-actions]

Thanks for opening this pull request! A SPACE maintainer will take a look.

CONTRIBUTING.md explains how we review outside contributions.