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>

server/internal/clientapi/capabilities.go

@@ -0,0 +1,64 @@
+package clientapi
+
+import (
+	"net/http"
+
+	"github.com/dariuszjaniak/warp/server/internal/httputil"
+	"github.com/dariuszjaniak/warp/server/internal/userapi"
+)
+
+// DefaultRoomVersion is what this server creates rooms at.
+//
+// PLAN.md's decision is to implement the latest stable room version first
+// and backfill older ones only as federation needs them, so the registry
+// here has exactly one entry until the event core lands in Phase 2.
+const DefaultRoomVersion = "11"
+
+// roomVersionsCapability is the m.room_versions capability.
+type roomVersionsCapability struct {
+	Default   string            `json:"default"`
+	Available map[string]string `json:"available"`
+}
+
+// booleanCapability is the shape of the several capabilities that are only
+// an on/off switch.
+type booleanCapability struct {
+	Enabled bool `json:"enabled"`
+}
+
+type capabilitiesResponse struct {
+	Capabilities capabilities `json:"capabilities"`
+}
+
+type capabilities struct {
+	RoomVersions    roomVersionsCapability `json:"m.room_versions"`
+	ChangePassword  booleanCapability      `json:"m.change_password"`
+	SetDisplayName  booleanCapability      `json:"m.set_displayname"`
+	SetAvatarURL    booleanCapability      `json:"m.set_avatar_url"`
+	ThreePIDChanges booleanCapability      `json:"m.3pid_changes"`
+}
+
+// handleCapabilities implements GET /_matrix/client/v3/capabilities.
+//
+// The endpoint needs a token: what a server will let you do depends on who
+// you are, and the spec makes it authenticated for that reason.
+//
+// Every flag here is the truth about this build, not an aspiration.
+// Password changes and third-party identifiers arrive with the rest of
+// account management in Phase 9, so they report false and clients hide the
+// buttons rather than offering something that 404s.
+func (c *ClientAPI) handleCapabilities(w http.ResponseWriter, _ *http.Request, _ userapi.Authenticated) error {
+	httputil.WriteJSON(w, http.StatusOK, capabilitiesResponse{
+		Capabilities: capabilities{
+			RoomVersions: roomVersionsCapability{
+				Default:   DefaultRoomVersion,
+				Available: map[string]string{DefaultRoomVersion: "stable"},
+			},
+			ChangePassword:  booleanCapability{Enabled: false},
+			SetDisplayName:  booleanCapability{Enabled: true},
+			SetAvatarURL:    booleanCapability{Enabled: true},
+			ThreePIDChanges: booleanCapability{Enabled: false},
+		},
+	})
+	return nil
+}