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

internal/api/teams.go

@@ -51,6 +51,68 @@ func handleListTeams(db *sql.DB) http.HandlerFunc {
 	}
 }
 
+// handleUserTeams lists one user's teams, for the admin page's per-user view:
+// "what is this person in", which /api/teams cannot answer because it is always
+// about the caller.
+//
+// Self or admin, matching the other per-user endpoints. It says which teams
+// somebody belongs to and in what role — not anything those teams own, so it
+// stays on the accounts side of the line the administrator flag draws.
+func handleUserTeams(db *sql.DB) http.HandlerFunc {
+	return func(w http.ResponseWriter, r *http.Request) {
+		id, err := strconv.ParseInt(chi.URLParam(r, "id"), 10, 64)
+		if err != nil {
+			respond(w, http.StatusBadRequest, errResp("invalid user id"))
+			return
+		}
+		if !requireSelfOrAdmin(w, r, id) {
+			return
+		}
+
+		// A user with no teams and a user who does not exist both list nothing,
+		// so the existence check is what tells them apart.
+		var exists bool
+		if err := db.QueryRowContext(r.Context(),
+			"SELECT EXISTS (SELECT 1 FROM users WHERE id = $1)", id).Scan(&exists); err != nil {
+			respond(w, http.StatusInternalServerError, errResp("internal error"))
+			return
+		}
+		if !exists {
+			respond(w, http.StatusNotFound, errResp("user not found"))
+			return
+		}
+
+		rows, err := db.QueryContext(r.Context(), `
+			SELECT t.id, t.name, t.created_at, m.role
+			FROM   teams t
+			JOIN   team_members m ON m.team_id = t.id
+			WHERE  m.user_id = $1
+			ORDER  BY t.name`, id)
+		if err != nil {
+			respond(w, http.StatusInternalServerError, errResp("internal error"))
+			return
+		}
+		defer rows.Close()
+
+		teams := []models.Team{}
+		for rows.Next() {
+			var t models.Team
+			var created int64
+			if err := rows.Scan(&t.ID, &t.Name, &created, &t.Role); err != nil {
+				respond(w, http.StatusInternalServerError, errResp("internal error"))
+				return
+			}
+			t.CreatedAt = time.Unix(created, 0).UTC()
+			teams = append(teams, t)
+		}
+		if err := rows.Err(); err != nil {
+			respond(w, http.StatusInternalServerError, errResp("internal error"))
+			return
+		}
+		respond(w, http.StatusOK, teams)
+	}
+}
+
 // handleCreateTeam creates a team and makes its creator the first owner. A team
 // with no owner would need an administrator to repair before anybody could use
 // it, so the two happen in one transaction.