the owner is an identity, not a role

Roles and teams, phase 1. `isSuperAdmin` asked `user.role === 'Super Admin'`, which
was right while roles were a hardcoded union and nothing could write a new one. It
stopped being right the moment roles became a table: from then on "add a role" and
"become the owner" were the same feature, reachable from whatever UI manages roles.

So ownership is `OWNER_USER_ID` and nothing else. `isOwner` is the new name and
`isSuperAdmin` delegates to it, so no call site changes who it admits — widening any
"owner-only" route to "owner or Super Admin" is a separate decision per route, not a
side effect of this.

Still a database read rather than a bare comparison: a deleted or blocked account
must not remain the owner because its id happens to match.

`getOwnerUser` becomes a primary-key lookup. It used to select on the role with
`order by id` as a tiebreak, because two holders would otherwise make "who owns this
server" whatever Postgres returned first — an answer that decides the agent
sidecar's identity, vault access and origin scoping. That tiebreak, the write-path
refusals and the CHECK all protected an answer that is now a primary key.

Several Super Admins are allowed. What the role carries is real and belongs in the
UI rather than a refusal here: it provisions an OS account with sudo, which puts the
holder outside Officer's permission system and cannot be undone by revoking the role
afterwards. That is the operator's decision, not this endpoint's.

Two departures from docs/roles-and-teams.md, both recorded there. The CHECK pinning
user 1's role is KEPT — redundant for ownership, but it still forbids the owner
being set to Member, which is a nonsense state that costs nothing to prevent. And
promotion to Super Admin is allowed while creating an account directly as one is
not: promotion happens to an account somebody has looked at, creation is a form
filled once, and the role that grants sudo should not be a dropdown default.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

src/databases/officer_db/src/auth/queries.ts

@@ -85,14 +85,18 @@ export async function getUserByUsername(username: string): Promise<UserSelect |
 // #1. Returns undefined rather than falling back to the lowest id when no row holds the role: the agent
 // sidecar refusing to start beats it silently running as the wrong person.
 //
-// `order by id` is not cosmetic. Without it, two rows holding the role would make "who owns this
-// server" whatever Postgres happened to return first — and that answer feeds the agent sidecar's
-// identity, the vault and origin scoping. The write paths refuse to create a second Super Admin
-// (create-user.ts and updateUserRoleHandler), so this should never have a choice to make; ordering is
-// what makes the outcome deterministic if one ever gets in by another route, and id 1 is the bootstrap
-// account the CHECK constraint already pins.
+// The owner is `OWNER_USER_ID`, so there is nothing to disambiguate and no ordering to get right.
+//
+// This used to select on `role = 'Super Admin'` with `order by id` as a tiebreak, because two rows could
+// hold the role and "who owns this server" would otherwise be whatever Postgres returned first — an answer
+// that feeds the agent sidecar's identity, the vault and origin scoping. The write paths refused a second
+// Super Admin to keep it single.
+//
+// Since 2026-08-23 ownership is an identity, so several accounts may hold `Super Admin` and none of them
+// becomes the owner by doing so. The tiebreak, the refusals and the CHECK that pinned user 1's role all
+// existed to protect an answer that is now a primary key.
 export async function getOwnerUser(): Promise<UserSelect | undefined> {
-  const [user] = await db.select().from(users).where(eq(users.role, 'Super Admin')).orderBy(users.id).limit(1);
+  const [user] = await db.select().from(users).where(eq(users.id, OWNER_USER_ID)).limit(1);
   return user;
 }
 

src/databases/officer_db/src/auth/schema.ts

@@ -93,6 +93,15 @@ export const users = pgTable(
     // "some row must be Super Admin" — that would need to see other rows. So this pins the bootstrap
     // account and nothing more; promoting or demoting anyone else is still free.
     //
+    // KEPT after ownership stopped being a role, 2026-08-23, and `docs/roles-and-teams.md` phase 1 said to
+    // remove it as redundant. It is redundant for the question it was written for — `isOwner` is now an id
+    // comparison and does not read this column at all — but it still earns its place for a different one:
+    // it stops user 1 being set to `Member` while remaining the owner, which is a state with no benefit and
+    // a confusing display. A constraint that costs nothing and forbids a nonsense state is worth keeping
+    // even after the reason it was added has gone.
+    //
+    // What it must NOT be mistaken for is the thing that makes user 1 the owner. It does not, any more.
+    //
     // It cannot stop a DELETE either. deleteUser() in queries/auth.ts refuses id 1 for that half.
     //
     // sql.raw for the literal — an interpolated JS string binds as `$1`, and Postgres will not accept a