Add Roles & Admin/Super-Admin interface

Per organized-ideas.md §6: role assignment, account ban/unban/delete, and
direct Admin/Super-Admin CRUD of public catalog entries outside the
submission workflow.

Backend:
- list_users_for_admin(): Super-Admin-gated SECURITY DEFINER function
  joining profiles + auth.users (username, email, role, banned_until) —
  auth.users isn't exposed through PostgREST, so this is the only way to
  list accounts at all.
- New Edge Function admin-user-action (ban/unban/delete), using
  @supabase/server's `auth: 'user'` mode to verify the caller's JWT, then
  Supabase Auth's Admin API for the actual mutation. This is deliberately
  an Edge Function rather than a Postgres function like everything else in
  this codebase: touching auth.users needs the Admin API, the stable
  documented interface, not a direct write to a schema Supabase manages
  internally. Self-action guard; verify_jwt = true at the gateway on top of
  the function's own JWT verification.
- 5 new pgTAP tests (43/43 total) for list_users_for_admin (Super-Admin-only,
  even regular Admins get 42501).
- CatalogRepository gains admin* methods (direct edit of a public port/cable/
  device entry, plus adminUnpublish which flips is_public rather than
  deleting) — the update methods were already ownership-agnostic (RLS's
  is_admin() clause is what actually permits it), so these are thin aliases,
  not duplicated logic.

Frontend:
- authStore/AdminUserRepository: minimal role plumbing, shared UserRole type.
- adminUserStore + AdminUsersModal: list/role-dropdown/ban/unban/delete,
  gated to Super Admin only via a new "Manage Users" TopBar button.
- PortTypeManager/CableTypeManager/DevicePalette: built-in entries now show
  direct "Edit"/"Unpublish" for Admins (regular Admin included, per §6's
  capability table — not Super-Admin-exclusive) instead of "Suggest edit";
  unpublish reuses the review-queue's impact-check RPC before confirming.
- DeviceTemplateEditor gains an `adminMode` save path alongside its existing
  submissionMode/resubmitId ones.

Verified: tsc -b and oxlint clean; supabase db reset + 43/43 pgTAP tests
pass; confirmed both new privileged endpoints (the SQL function and the
Edge Function) actually work through the real REST API via live curl
calls — signup, email confirm, role promotion, ban/unban/delete round
trips, self-action guard, non-super-admin rejection, and verify_jwt=true
compatibility all exercised directly, not just asserted.

src/data/AdminUserRepository.ts

@@ -0,0 +1,32 @@
+/** A user's role — mirrors `profiles.role`'s check constraint. Defined here
+ *  (data layer) rather than in state/authStore.ts so both that store and
+ *  this repository share one definition without state importing from data
+ *  in the wrong direction. */
+export type UserRole = 'regular' | 'admin' | 'super_admin'
+
+export interface AdminUserSummary {
+  id: string
+  username: string
+  email: string
+  role: UserRole
+  /** Set (a future timestamp) while banned; undefined otherwise. */
+  bannedUntil?: string
+  createdAt: string
+}
+
+/** Storage abstraction for Super-Admin user management (organized-ideas.md
+ *  §6's "CRUD user accounts"). Listing and role changes are plain
+ *  RLS/privileged-function reads and writes; ban/unban/delete go through
+ *  the admin-user-action Edge Function since those specifically need
+ *  Supabase Auth's Admin API — see that function's own header comment for
+ *  why this can't just be another SQL function like the rest. */
+export interface AdminUserRepository {
+  listUsers(): Promise<AdminUserSummary[]>
+  updateRole(userId: string, role: UserRole): Promise<void>
+  /** Reversible — blocks login without touching the account's data. */
+  banUser(userId: string): Promise<void>
+  unbanUser(userId: string): Promise<void>
+  /** Irreversible — cascades to the user's profile, diagrams, and owned
+   *  private catalog entries via their existing foreign keys. */
+  deleteUser(userId: string): Promise<void>
+}

src/data/CatalogRepository.ts

@@ -1,3 +1,4 @@
+import type { CatalogEntityType } from './SubmissionRepository'
 import type { Catalog, CableType, DeviceCategoryDef, DeviceTemplate, PortType } from '../domain/types'
 
 /**
@@ -7,10 +8,14 @@ import type { Catalog, CableType, DeviceCategoryDef, DeviceTemplate, PortType }
  * entries plus their own private ones); RLS does that filtering server-side,
  * so implementations don't need to filter client-side.
  *
- * Only covers the "read + manage your own private entries" surface for now.
- * Submitting a private entry for public review/promotion is a separate,
- * not-yet-built workflow (organized-ideas.md §3/§9) — these `add*`/`update*`
- * methods always create or edit is_public = false rows you own.
+ * The `add*`/`update*` methods always create or edit an `is_public = false`
+ * row you own — that's the regular-user "own private catalog" surface.
+ * Getting an entry into the public catalog otherwise goes through the
+ * submission/review workflow (organized-ideas.md §3), except for the
+ * `admin*` methods below: per §6's capability table, an Admin/Super-Admin
+ * can also CRUD public entries directly, without a submission — those
+ * bypass ownership entirely (RLS's `is_admin()` clause is what actually
+ * allows it) and only ever touch already-public rows.
  */
 export interface CatalogRepository {
   /** Everything visible to the current user: public entries plus their own private ones. */
@@ -27,4 +32,16 @@ export interface CatalogRepository {
   addDeviceTemplate(template: Omit<DeviceTemplate, 'id' | 'custom'>): Promise<DeviceTemplate>
   updateDeviceTemplate(id: string, patch: Partial<Omit<DeviceTemplate, 'id' | 'custom'>>): Promise<void>
   removeDeviceTemplate(id: string): Promise<void>
+
+  /** Admin/Super-Admin direct edit of an already-public port/cable/device
+   *  entry — same underlying write as approving a submission, minus the
+   *  submission. */
+  adminUpdatePortType(id: string, patch: Partial<Omit<PortType, 'id' | 'custom'>>): Promise<void>
+  adminUpdateCableType(id: string, patch: Partial<Omit<CableType, 'id' | 'custom'>>): Promise<void>
+  adminUpdateDeviceTemplate(id: string, patch: Partial<Omit<DeviceTemplate, 'id' | 'custom'>>): Promise<void>
+  /** Unpublishes a public entry (is_public -> false) rather than deleting
+   *  it — organized-ideas.md §3's "public catalog entries are never hard-
+   *  deleted, only hidden/unpublished". Existing diagrams that reference it
+   *  by id are unaffected; it just stops being offered for new use. */
+  adminUnpublish(entityType: CatalogEntityType, id: string): Promise<void>
 }

src/data/SupabaseAdminSubmissionRepository.ts

@@ -1,16 +1,10 @@
 import { v4 as uuid } from 'uuid'
 import type { AdminSubmissionRepository, UsageImpact, UsageImpactSample } from './AdminSubmissionRepository'
+import { CATALOG_TABLE_BY_ENTITY_TYPE } from './catalogRowMapping'
 import type { CatalogSubmission } from './SubmissionRepository'
 import { supabase } from './supabaseClient'
 import { toSubmission, type SubmissionRow } from './submissionRowMapping'
 
-const TABLE_BY_ENTITY_TYPE: Record<CatalogSubmission['entityType'], string> = {
-  device_template: 'device_templates',
-  port_type: 'port_types',
-  cable_type: 'cable_types',
-  device_category: 'device_categories',
-}
-
 interface ProposedDeviceTemplatePort {
   name: string
   direction: string
@@ -45,7 +39,7 @@ export class SupabaseAdminSubmissionRepository implements AdminSubmissionReposit
     // `ports` (device_template only) isn't a column on device_templates
     // itself; pull it out and replace device_template_ports separately.
     const { ports, ...rowPatch } = submission.proposedData as Record<string, unknown> & { ports?: ProposedDeviceTemplatePort[] }
-    const table = TABLE_BY_ENTITY_TYPE[submission.entityType]
+    const table = CATALOG_TABLE_BY_ENTITY_TYPE[submission.entityType]
     const { error } = await supabase
       .from(table)
       .update({ ...rowPatch, is_public: true, owner_id: null })

src/data/SupabaseAdminUserRepository.ts

@@ -0,0 +1,73 @@
+import { FunctionsHttpError } from '@supabase/supabase-js'
+import type { AdminUserRepository, AdminUserSummary, UserRole } from './AdminUserRepository'
+import { supabase } from './supabaseClient'
+
+interface UserRow {
+  id: string
+  username: string
+  email: string
+  role: UserRole
+  banned_until: string | null
+  created_at: string
+}
+
+function toSummary(row: UserRow): AdminUserSummary {
+  return {
+    id: row.id,
+    username: row.username,
+    email: row.email,
+    role: row.role,
+    bannedUntil: row.banned_until ?? undefined,
+    createdAt: row.created_at,
+  }
+}
+
+type UserAction = 'ban' | 'unban' | 'delete'
+
+/** Backs the app with list_users_for_admin (read), a direct profiles.role
+ *  update, and the admin-user-action Edge Function (ban/unban/delete). */
+export class SupabaseAdminUserRepository implements AdminUserRepository {
+  async listUsers(): Promise<AdminUserSummary[]> {
+    const { data, error } = await supabase.rpc('list_users_for_admin')
+    if (error) {
+      console.error('Failed to list users from Supabase', error)
+      return []
+    }
+    return ((data ?? []) as UserRow[]).map(toSummary)
+  }
+
+  async updateRole(userId: string, role: UserRole): Promise<void> {
+    const { error } = await supabase.from('profiles').update({ role }).eq('id', userId)
+    if (error) console.error('Failed to update user role in Supabase', error)
+  }
+
+  private async invokeUserAction(action: UserAction, userId: string): Promise<void> {
+    const { error } = await supabase.functions.invoke('admin-user-action', { body: { action, userId } })
+    if (!error) return
+
+    // The function returns its actual reason (e.g. "Only a Super Admin can
+    // manage user accounts.") in the JSON body on a non-2xx response —
+    // surface that instead of supabase-js's generic "Edge Function
+    // returned a non-2xx status code" wrapper.
+    if (error instanceof FunctionsHttpError) {
+      const body = await error.context.json().catch(() => null)
+      const message = typeof body?.error === 'string' ? body.error : error.message
+      console.error(`Failed to ${action} user`, message)
+      throw new Error(message)
+    }
+    console.error(`Failed to ${action} user`, error)
+    throw error
+  }
+
+  banUser(userId: string): Promise<void> {
+    return this.invokeUserAction('ban', userId)
+  }
+
+  unbanUser(userId: string): Promise<void> {
+    return this.invokeUserAction('unban', userId)
+  }
+
+  deleteUser(userId: string): Promise<void> {
+    return this.invokeUserAction('delete', userId)
+  }
+}

src/data/SupabaseCatalogRepository.ts

@@ -1,7 +1,8 @@
 import { v4 as uuid } from 'uuid'
 import type { Catalog, CableType, DeviceCategoryDef, DeviceTemplate, Port, PortType } from '../domain/types'
-import { cableTypeToRow, deviceTemplateToRow, portTypeToRow } from './catalogRowMapping'
+import { CATALOG_TABLE_BY_ENTITY_TYPE, cableTypeToRow, deviceTemplateToRow, portTypeToRow } from './catalogRowMapping'
 import type { CatalogRepository } from './CatalogRepository'
+import type { CatalogEntityType } from './SubmissionRepository'
 import { supabase } from './supabaseClient'
 
 interface DeviceCategoryRow {
@@ -260,4 +261,28 @@ export class SupabaseCatalogRepository implements CatalogRepository {
     const { error } = await supabase.from('device_templates').delete().eq('id', id)
     if (error) console.error('Failed to remove device template from Supabase', error)
   }
+
+  // The update* methods above never check ownership themselves — RLS does,
+  // server-side, based on the caller's identity — so an Admin/Super-Admin
+  // direct edit of a public entry is *exactly* the same write, just
+  // permitted by a different branch of the same policy (`is_admin()`
+  // instead of "owns it and it's still private"). These are aliases, not
+  // separate logic, so the two paths can't drift apart.
+  adminUpdatePortType(id: string, patch: Partial<Omit<PortType, 'id' | 'custom'>>): Promise<void> {
+    return this.updatePortType(id, patch)
+  }
+
+  adminUpdateCableType(id: string, patch: Partial<Omit<CableType, 'id' | 'custom'>>): Promise<void> {
+    return this.updateCableType(id, patch)
+  }
+
+  adminUpdateDeviceTemplate(id: string, patch: Partial<Omit<DeviceTemplate, 'id' | 'custom'>>): Promise<void> {
+    return this.updateDeviceTemplate(id, patch)
+  }
+
+  async adminUnpublish(entityType: CatalogEntityType, id: string): Promise<void> {
+    const table = CATALOG_TABLE_BY_ENTITY_TYPE[entityType]
+    const { error } = await supabase.from(table).update({ is_public: false }).eq('id', id)
+    if (error) console.error('Failed to unpublish catalog entry in Supabase', error)
+  }
 }

src/data/catalogRowMapping.ts

@@ -1,3 +1,4 @@
+import type { CatalogEntityType } from './SubmissionRepository'
 import type { CableType, DeviceTemplate, PortType } from '../domain/types'
 
 /**
@@ -10,6 +11,16 @@ import type { CableType, DeviceTemplate, PortType } from '../domain/types'
  * step an Admin's approval action would otherwise have to duplicate.
  */
 
+/** Which table backs each catalog entity type — shared by
+ *  SupabaseAdminSubmissionRepository (approving into the right table) and
+ *  SupabaseCatalogRepository (direct Admin unpublish). */
+export const CATALOG_TABLE_BY_ENTITY_TYPE: Record<CatalogEntityType, string> = {
+  device_template: 'device_templates',
+  port_type: 'port_types',
+  cable_type: 'cable_types',
+  device_category: 'device_categories',
+}
+
 export function portTypeToRow(portType: Omit<PortType, 'id' | 'custom'>): Record<string, unknown> {
   return {
     name: portType.name,