the owner can create accounts

POST /api/users plus an Add-account form in Settings > User management. Until now
createUser had one call site — bootstrap, gated on an empty user table — so every
non-owner account anywhere had been inserted into Postgres by hand.

Created accounts are Active. The column defaults to Unverified and signin refuses
anything else with a bare UNAUTHORIZED, which is exactly what made the hand-INSERT
route look like a wrong password.

Also closes a hole found while reading the write path: a second Super Admin was
storable. The CHECK constraint pins user 1's role but cannot see other rows, and
getOwnerUser() was LIMIT 1 with no ORDER BY, so two holders would have made "who owns
this server" a question the query plan answered — and that answer feeds the agent
sidecar's identity, vault access and origin scoping. Both write paths now refuse the
role and getOwnerUser() orders by id.

USER_DIRS and provisionUserDirs move into data-path.ts so the create handler and
scripts/provision-user-dirs.ts cannot disagree about what an account's skeleton is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

TODO.md

@@ -14,10 +14,26 @@ the owner's OS user and can never be granted. Indirection there really is accide
 
 ## Multi-user
 
-- [ ] **No way to create a second account.** `createUser` has one call site, `auth/bootstrap.ts`, gated
-      on an empty user table. There is no signup route, no invite flow and no admin create-user
-      handler, so every member on this instance was inserted into Postgres by hand. This is the
-      blocker for onboarding anyone who is not already in the database.
+- [x] **No way to create a second account.** Fixed 2026-08-11 on `sidecar-app-store`: `POST /api/users`
+      (`api/users/create-user.ts`, owner-gated) plus an Add-account form in
+      Settings → User management. Created accounts are `status: 'Active'` — the column defaults to
+      `'Unverified'` and `signin.ts` refuses anything else with a bare UNAUTHORIZED, which is the trap
+      the hand-INSERT route fell into. The owner sets the password and reads it out; `passwordChangedAt`
+      stays null. Directories come from the shared `provisionUserDirs`/`USER_DIRS` in `data-path.ts`,
+      which `scripts/provision-user-dirs.ts` now imports rather than restating.
+
+- [ ] **Still no invite flow, and no password reset for a member.** The owner types the password and
+      tells the person, which means the owner knows it and the member cannot change it back if they
+      forget theirs — recovery today is delete-and-recreate. An invite (token, expiry, member sets
+      their own) needs a mail path. This is the next piece, not a nice-to-have.
+
+- [x] **A second Super Admin was storable, and made the owner nondeterministic.** Fixed 2026-08-11.
+      `ck_users_owner_is_super_admin` pins user 1's role but a row-level CHECK cannot see other rows, and
+      `updateUserRoleHandler` happily promoted anyone — while `getOwnerUser()` was
+      `WHERE role='Super Admin' LIMIT 1` with no ORDER BY. Two holders would have made "who owns this
+      server" a question the query plan answered, and that answer feeds the agent sidecar's identity,
+      vault access and origin scoping. Both write paths now refuse the role, the list endpoint offers
+      `assignableRoles` without it, and `getOwnerUser()` orders by id.
 
 - [ ] **`dashboards.id` is a global primary key, and ids are `slugify(name)`.** Two accounts cannot
       both have a dashboard named "Home". Reachable today: six accounts exist. The recommendation on