Make the admin a member with a flag, and drop the second listener

The admin was a set of env credentials on its own loopback listener. That
bought network isolation, and charged a second port to tunnel and proxy and
a second credential in the password manager. It also sat outside the
SameSite protection the member cookie already had, and left every ban and
password reset with no actor to log.

is_admin on users reuses what was already there: the session, the login
rate limiter, ban-drops-sessions, CSRF. /admin is now a route on the member
mux. A member without the flag gets 404 rather than 403 — the pages are
none of their business, and "forbidden" confirms there is something to be
forbidden from.

Registration needs an invite and invites come from /admin, so an empty
database cannot grow its first user. seedAdmin breaks that circle exactly
once, from ADMIN_EMAIL and ADMIN_PASSWORD, and does nothing against a
database that already has users.

An admin cannot ban themselves: banning drops the target's sessions, and
nothing would be left that could undo it.

This reverses decision 8, which is rewritten rather than deleted, along
with the admin entry in the CONTEXT.md vocabulary.

migrations/002_users_is_admin.sql

@@ -0,0 +1,8 @@
+-- The admin became an ordinary account with a flag, so the separate Basic Auth listener could go.
+-- Same integer-as-boolean convention as `banned` above it.
+alter table users add column is_admin integer not null default 0;
+
+-- An existing database already has its admin sitting in row one: the person who was handed the
+-- first invite from the old panel. A fresh database has no rows, so this is a no-op there and
+-- seedAdmin creates the account from the environment instead.
+update users set is_admin = 1 where id = (select min(id) from users);