Manage a person's account and teams from one page

The Admin tab could make somebody an administrator and disable them, and
nothing else. Setting a first password, deleting an account and seeing
which teams a person is in all meant curl, and the last one meant opening
each team in turn — the Team tab answers "who is in this team", which is
the wrong way round when the question is about a person.

A name in the user list now opens /admin/users/{id}: their email and when
they joined, where their notifications go, the administrator and disabled
flags, the teams they are in with their role in each, a password field
for a first or forgotten one, and deletion. A section of its own rather
than an expanding row, because memberships and the account actions
together are more than a table row can hold and still be read on a phone.

Adding somebody mints an invite link into a chosen team rather than
creating a bare account. POST /api/users makes a user with no password
and no team, who can sign in nowhere and would see nothing if they did;
the invite machinery from #7 already solves both, and the password is
chosen by the person it belongs to instead of passing through an
administrator.

One new endpoint, GET /api/users/{id}/teams, self or admin. /api/teams is
always about the caller and cannot be asked about anybody else. It 404s
for a user who does not exist, so the page can tell "in no teams" from
"no such person" — an empty list is a real answer and needed to stay one.

No authorisation changed, and the interesting part is why it did not.
requireTeamOwner has accepted the administrator flag since a4fbd60, with
the reason in its own comment: somebody has to be able to repair a team
whose owner has left. It guards nine call sites, so an administrator has
always been able to configure any team on this server — while #1's
decision table and this README both said an admin "is not implicitly in
every team", full stop. The code was right and the prose was wrong in the
safe-sounding direction, which is the worse way round to have it.

So the documentation moved to meet the code. The Teams table marks owner
as owner-or-admin, and the Authentication section states the two
directions separately: an administrator configures any team, and reads
none, because callerTeamIDs is built from real memberships only. Joining
a team to see its queue is a membership change and shows as one.

TestAdmin_ConfiguresATeamTheyAreNotIn pins both halves — the admin
renames, invites, adds and removes on a team they are not in, then sees
zero of its incidents. Nothing tested this from v0.12.0 to here, which is
why four releases of prose could contradict it quietly.

The UI has not been opened in a browser. Its wiring is checked — every
cross-module import resolves, every api.* call exists, every CSS class
has a rule, and the deep link serves index.html — but nobody has clicked
through it, least of all at phone width.

Claude-Session: https://claude.ai/code/session_01RHPj4ggeFdEjKKfm4SHbD7

README.md

@@ -51,7 +51,7 @@ archive), who is on call, the alert feed, and changing your own password. It is
 built for a phone first. On a phone it has a bottom tab bar and a sticky action
 bar, it follows the system's dark mode, and it can be added to the home screen.
 From 900px wide it switches to a sidebar with the queue and the incident side by
-side. Schedule editing, statistics and user management remain in
+side. Statistics remain in
 [terdut-tui](https://github.com/yeniklas/terdut-tui) for now.
 
 You sign in with a username and password. Users have no password until one is
@@ -93,7 +93,19 @@ between them at the top.
 
 The **Admin** tab appears only for a system administrator, and holds what
 belongs to the whole server rather than to one team: every team, every user, and
-the settings that used to be environment variables.
+the settings that used to be environment variables. Adding somebody is minting
+them an invite link into a team, rather than creating a bare account: the person
+who accepts it picks their own password, so one never passes through an
+administrator, and the link carries the team, so they land somewhere with a
+queue in it.
+
+A name in that list opens **that person's page**, at `/admin/users/{id}`: their
+email and when they joined, where their notifications go, whether they are an
+administrator, whether the account is disabled, the teams they are in with their
+role in each, a password field for a first or forgotten one, and deletion. It is
+the one place membership is edited from the person's side — the Team tab answers
+"who is in this team", and answering "which teams is this person in" there means
+visiting each team in turn.
 
 ### Docker
 
@@ -579,10 +591,16 @@ Endpoints that require the flag answer `403` with
 
 **Teams** are the unit of tenancy, and are a separate axis from the administrator
 flag. A team owns its incidents, alerts, schedule and integrations, and a user
-sees exactly the teams they belong to — an administrator is not implicitly in
-every team, because administration is about accounts, not about reading other
-people's incidents. Within a team an **owner** configures it (schedule,
-integrations, membership) and a **member** works its incidents.
+sees exactly the teams they belong to. Within a team an **owner** configures it
+(schedule, integrations, membership) and a **member** works its incidents.
+
+An administrator crosses that line in one direction only. They **configure any
+team** without being in it — every owner-only endpoint accepts the flag, because
+otherwise a team whose last owner left could never be repaired. They do **not
+read any team**: the queue, the alerts and the incidents are filtered by real
+membership, so an administrator sees a team's work only by joining it, which is
+a membership change and shows up as one. Administration is about accounts and
+the shape of a team, not about reading other people's incidents.
 
 Anything belonging to a team you are not in answers `404`, not `403`: whether an
 incident exists is itself something only its team should learn.
@@ -607,6 +625,7 @@ on anybody's.
 | `POST` | `/api/signup` | — | Create an account `{"username","email","password","invite"?,"team_name"?}` and sign in. `403` without a usable invite when the mode is invite-only |
 | `POST` | `/api/bootstrap` | — | Create first user + API key `{"username","email","password"?}` (only works on empty DB). The user is an administrator |
 | `GET` | `/api/users` | any | List users. Open to everybody: the queue's assignment control and the schedule both have to name people |
+| `GET` | `/api/users/{id}/teams` | self or admin | The teams that user is in, each with their role. `/api/teams` is always about the caller; this one answers it about somebody else, for the admin page's per-user view. `404` for a user who does not exist, so "no teams" and "no such person" are distinguishable |
 | `POST` | `/api/users` | **admin** | Create user `{"username","email"}`. Not an administrator |
 | `DELETE` | `/api/users/{id}` | **admin** | Delete user (cascades to keys). `409` for yourself or the last administrator |
 | `PUT` | `/api/users/{id}/admin` | **admin** | Grant or revoke the administrator flag `{"is_admin"}`. `409` for yourself or the last administrator |
@@ -641,6 +660,11 @@ and was removed in v0.13.0 once senders had moved onto keys.
 
 ### Teams
 
+**owner** below means an owner of that team *or* a system administrator, who
+passes every one of these without being a member — see
+[Authentication](#authentication). **member** means membership and nothing else: an
+administrator who is not in the team gets the same `404` as anybody else.
+
 | Method | Path | Who | Description |
 |---|---|---|---|
 | `GET` | `/api/teams` | any | The caller's own teams, each with their role |