Phase 1: accounts and sessions

Implements PLAN.md Phase 1. A client can now register, log in, manage its
devices and set its profile; an operator can create accounts and flip the
runtime switches. There are still no rooms and no real /sync.

userapi: accounts, argon2id passwords in PHC format, devices, access and
refresh tokens stored as SHA-256 hashes, account data and the admin flag.
Its storage interface is storage.UserStore, implemented once in sqlstore
with `?` placeholders; the postgres driver supplies a rebind function and
unique-violation recognition rather than keeping a second copy of thirty
statements. Timestamps in these tables are int64 milliseconds, the unit the
Client-Server API uses on the wire.

Client-Server API: register (user-interactive auth with m.login.dummy and
optional registration tokens), register/available, token validity, login
with m.login.password, logout, logout/all, refresh, account/whoami,
capabilities, devices/* with password-gated deletion, profile/*, global and
per-room account data.

GET /sync is a deliberate placeholder: it answers a valid token with an
empty but well-formed response and refuses a revoked one. Phase 1 has no
rooms, so that is the whole truth, and it is what makes session revocation
observable. Phase 4 replaces it with the syncapi.

Auth middleware resolves a bearer token (header or the legacy query
parameter) to a device and user, answering an expired token with the soft
logout the spec asks for. Rate limiting is a token bucket per endpoint class
keyed on the client address, returning M_LIMIT_EXCEEDED with retry_after_ms.

adminapi v1 under /_warp/admin/v1: admin-only auth via a normal Matrix
token, GET/PUT /federation and /registration driving internal/settings and
reporting a config-pinned switch as a 409, GET/POST /users, GET /stats.

warp create-account [--admin] creates the first account straight in the
database, so a new install with registration off has a way in.

Complement is wired up for the federation=off profile: an image meeting its
contract, an entrypoint that configures Warp entirely from WARP_*
variables, and a runner that builds, clones and executes the target set
(TestRegistration, TestLogin, TestDeviceManagement). It has not been run
yet -- there is no container runtime on the development machine -- so the
three tests' assertions were read from the Complement sources and pinned as
httptest tests instead, and CI gained a job that runs the real thing.

Also fixes a .gitignore bug from Phase 0: the unanchored `warp` pattern,
meant for the built binary, also matched the directory server/cmd/warp and
silently excluded the entire command package from the repository. The
binary patterns are now anchored to the repository root, and cmd/warp is
committed for the first time.

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

docs/admin-api.md

@@ -0,0 +1,137 @@
+# Admin API
+
+Everything under `/_warp/admin/v1` is Warp's own, not Matrix. Clients use
+the Client-Server API; this is the operator's surface and the backend for
+the admin panel (`apps/admin`, PLAN.md section 8.1).
+
+## Authentication
+
+A normal Matrix access token belonging to an account with the admin flag.
+The panel logs in the way any client does, so there is no second credential
+to manage:
+
+```sh
+TOKEN=$(curl -s localhost:8008/_matrix/client/v3/login \
+  -d '{"type":"m.login.password","identifier":{"type":"m.id.user","user":"root"},"password":"..."}' \
+  | jq -r .access_token)
+
+curl localhost:8008/_warp/admin/v1/stats -H "Authorization: Bearer $TOKEN"
+```
+
+The token must be in the `Authorization` header. Unlike the C-S API, the
+`?access_token=` form is not accepted here: an admin token in a URL ends up
+in every access log between the browser and the server.
+
+A valid token without the admin flag gets `403 M_FORBIDDEN` rather than a
+404. The caller is a legitimate user of this server who is not allowed here,
+and pretending the endpoint does not exist only makes the panel harder to
+debug.
+
+Make the first admin from the command line:
+
+```sh
+./bin/warp create-account --username root --admin
+```
+
+## Endpoints
+
+### `GET /federation`, `PUT /federation`
+
+The runtime federation switch of PLAN.md section 3.
+
+```json
+{
+  "enabled": false,
+  "toggleable": true,
+  "allowlist": [],
+  "denylist": []
+}
+```
+
+`PUT {"enabled": true}` takes effect on the next request, with no restart,
+and answers with the same document. `toggleable` is `false` when
+`federation.allow_runtime_toggle` pinned the setting in the config file; a
+`PUT` then returns `409` and the panel should grey the switch out rather
+than offer something that will bounce.
+
+Editing the allow and deny lists is Phase 9. They are reported now because
+the dashboard has to show which servers a running Warp will talk to.
+
+### `GET /registration`, `PUT /registration`
+
+The same shape, without the lists, for open registration.
+
+### `GET /users`
+
+```
+GET /users?search=ali&limit=50&offset=0
+```
+
+Ordered by localpart. `search` matches a substring of the localpart or the
+display name, case-insensitively. `total` is the number of users matching
+the query rather than the number returned, so the panel can page.
+
+```json
+{
+  "users": [
+    {
+      "user_id": "@alice:warp.example",
+      "display_name": "Alice",
+      "admin": false,
+      "deactivated": false,
+      "created_at_ms": 1760000000000
+    }
+  ],
+  "total": 1,
+  "limit": 50,
+  "offset": 0
+}
+```
+
+### `POST /users`
+
+```json
+{"username": "alice", "password": "...", "display_name": "Alice", "admin": false}
+```
+
+`201` with the created user. This is how an operator adds an account to a
+server with registration turned off — which is the normal state of a
+private Warp — so it ignores the registration switch deliberately: it is
+the admin's own action, not a public sign-up. `username` is normalised
+(lower-cased) like any other localpart. A taken name is
+`400 M_USER_IN_USE`, an unusable one `400 M_INVALID_USERNAME`.
+
+### `GET /stats`
+
+The dashboard payload.
+
+```json
+{
+  "server_name": "warp.example",
+  "version": "0.0.0-dev",
+  "database": "sqlite",
+  "users": 12,
+  "admins": 1,
+  "deactivated": 0,
+  "devices": 19,
+  "federation_enabled": false,
+  "registration_enabled": false
+}
+```
+
+Room and event counters join it in Phase 3, when there is something to
+count.
+
+## Errors
+
+The same envelope as the Client-Server API — `{"errcode": ..., "error":
+...}` — so the panel needs one error path, not two. `409 M_FORBIDDEN` is
+specific to this API: the request was well formed and the server's own
+configuration is what refuses it.
+
+## Not here yet
+
+Phase 9 completes the admin API: deactivating users, resetting passwords,
+revoking devices, granting the admin flag, registration token management,
+the federation allow/deny list editor, server notices, media quotas and an
+audit log of admin actions. Rooms arrive with the roomserver in Phase 3.