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/development.md

@@ -101,13 +101,61 @@ says why.
 
 ## Tests
 
-- Unit tests live next to the code. `internal/setup` holds the HTTP-level
-  tests; they build a whole server on an in-memory SQLite database.
+- Unit tests live next to the code. Each API package holds its own
+  HTTP-level tests, built on a throwaway SQLite database with the real
+  components behind them rather than fakes; `internal/setup` holds the
+  smaller set that goes through the whole wrapped handler, to catch a route
+  that was written but never registered.
 - Storage tests run against every driver that is available:
   SQLite always, PostgreSQL when `WARP_TEST_POSTGRES_DSN` is set.
 - CI runs `gofmt -l`, `go mod tidy` (as a diff check), `go vet`, the tests
   on Linux and Windows, the race detector on Linux, `golangci-lint`, and a
   smoke test that boots the real binary and curls it.
 
-Complement, the official integration suite, is wired up in Phase 1 — there
-is nothing it can test before registration exists.
+## Complement
+
+[Complement](https://github.com/matrix-org/complement) is the official Matrix
+integration suite. It runs a container per homeserver per test and drives it
+over the real HTTP API, which makes its pass count the honest measure of how
+far along the server is — PLAN.md section 9 treats it as the primary progress
+metric.
+
+```sh
+make complement                                   # the current target set
+server/test/complement/run.sh TestLogin           # one test
+COMPLEMENT_DEBUG=1 make complement                # with the container logs
+```
+
+It needs Docker. The script builds the image, clones Complement into
+`.complement/` (ignored by git) and runs the subset for the phases that are
+done — currently `TestRegistration`, `TestLogin` and `TestDeviceManagement`,
+with federation off. Extend `COMPLEMENT_TESTS` in
+[run.sh](../server/test/complement/run.sh) as each phase lands, rather than
+switching to the whole suite: a pass count that drops because a later phase
+is missing is noise.
+
+The image is [server/test/complement/Dockerfile](../server/test/complement/Dockerfile)
+and the deployment is entirely `WARP_*` environment variables — see
+[entrypoint.sh](../server/test/complement/entrypoint.sh). Two things there
+are worth knowing: rate limiting is off, because the whole suite comes from
+one address and would otherwise spend its time reading `M_LIMIT_EXCEEDED`;
+and port 8448 is exposed but nothing listens on it yet. The federation
+profile needs a TLS listener signed by the CA that Complement mounts at
+`/complement/ca`, which arrives with federation in Phase 5.
+
+## Creating the first account
+
+A new install has registration off, so the first account is made from the
+command line against the database directly — no server needs to be running:
+
+```sh
+./bin/warp create-account --username you --admin
+```
+
+It prompts for the password twice. `--password-file` reads it from a file and
+`--password` takes it inline, for scripts that have already thought about the
+shell history. From there, the admin API can turn registration on:
+
+```sh
+curl -X PUT http://localhost:8008/_warp/admin/v1/registration   -H "Authorization: Bearer $TOKEN" -d '{"enabled": true}'
+```