Add a system administrator role, and gate account management behind it

Until now every authenticated caller could create and delete users, set
anybody's password and mint anybody's API keys -- auth.go said so in a
comment. Defensible with one operator and a hand-made account; not once
people sign themselves up (#7), and not in a multi-tenant install (#4),
where the user list is no longer everybody who works here.

users.is_admin is the flag. AdminOnly gates creating and deleting users
and granting the flag itself. The endpoints that are self-service for
your own account and administration for somebody else's -- password,
ntfy topic, API keys -- go through requireSelfOrAdmin instead, because
which rule applies depends on the {id} in the path rather than on the
route.

Minting your own API key stays self-service. A key carries exactly the
rights of the user it belongs to, so issuing one is no more than signing
in again; requiring an admin for it would mean a responder cannot set up
the TUI without somebody else in the room.

/api/users stays readable by everybody. The queue's assignment control
and the on-call schedule both have to name people, and hiding the roster
from the people on it buys nothing.

THE MIGRATION MAKES EVERY EXISTING USER AN ADMINISTRATOR. They already
hold these powers, so nobody's access changes on upgrade: it names what
is already true and leaves demotion as a deliberate act. Promoting only
user 1 would silently strip the others, and could leave an install whose
only administrator is an account nobody has a password for.

Two guards keep an install administrable: the last administrator can be
neither deleted nor demoted, and nobody can delete or demote themselves
-- the likelier accident, where the only admin clears their own flag
while tidying up and locks the door behind them.

No UI changes: there are no account-management screens yet. models.User
carries is_admin (not omitempty, so a client can tell false from an old
server), which is what #5's admin page will render from.

internal/db/migrations/002_admin_role.sql

@@ -0,0 +1,25 @@
+-- A system administrator role, and the first thing in this server that one user
+-- can do and another cannot.
+--
+-- Until now every authenticated caller could create and delete users, set
+-- anybody's password and mint API keys for anybody — auth.go said so in a
+-- comment. That was defensible with one operator and a hand-made account; it is
+-- not once people sign themselves up (see #7).
+--
+-- EVERY EXISTING USER BECOMES AN ADMIN. They already hold these powers, so
+-- this migration changes nobody's access: it names what is already true, and
+-- leaves demotion as a deliberate act somebody performs afterwards. The
+-- alternative — promoting only user 1 — would silently strip the others, and
+-- could leave an install whose only admin is an account nobody has a password
+-- for.
+--
+-- New users are not admins: the column defaults to false, and the only ways to
+-- become one are this backfill, the bootstrap endpoint, or an existing admin
+-- granting it.
+ALTER TABLE users ADD COLUMN is_admin BOOLEAN NOT NULL DEFAULT false;
+
+UPDATE users SET is_admin = true;
+
+-- The queue's assignment dropdown and the on-call schedule read every user, and
+-- the admin screens in #5 will filter on this.
+CREATE INDEX users_is_admin_idx ON users(is_admin) WHERE is_admin;