Web client (warp-web) with E2EE, and two sync fixes

apps/web: a Matrix client for the browser on Vue 3, Tailwind and
matrix-js-sdk, built on @warp/ui. Like the admin panel it is an optional,
separate service: warp-web embeds the built app, serves /config.json and
proxies only /_matrix/client and /_matrix/media to the homeserver (or,
with -public-homeserver, lets the browser call it directly).
Sign-in and sign-up with registration tokens, room list, timeline with
back-pagination, text, images, video and files over authenticated media,
local echo with sent/read/failed states, receipts, typing, invites,
creating, joining and leaving rooms, room info, settings, phone layout.
End-to-end encryption through the Rust crypto: encrypted messages and
files, emoji verification, key backup setup and restore.

apps/ui: WRoomItem, WMessageBubble and WComposer from the brand package,
and the icons the client needs.

syncapi fixes found with the client:
- A room joined inside the sync window was sent as the join alone with
  limited: false, so clients thought they had the whole room. It is now
  read like an initial sync; a profile change is not mistaken for a join.
- A live typing notification was reported on every sync, so every long
  poll returned at once while anybody typed. Typing now has a position
  in the sync token and is reported when it changes, including the empty
  list when the last person stops.

Also: Dockerfile, a `web` compose profile, Makefile targets, a CI job
with a proxy smoke test, docs. PLAN.md moves out of the repository.

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

server/internal/syncapi/token.go

@@ -18,13 +18,13 @@ import (
 //
 // The wire form is
 //
-//	s{pdu}_{receipt}_{to_device}_{account_data}_{presence}_{device_list}_{notification}
+//	s{pdu}_{receipt}_{to_device}_{account_data}_{presence}_{device_list}_{notification}_{typing}
 //
 // with trailing zeroes left off, so a client that has only ever seen room
 // events carries "s12" rather than "s12_0_0_0_0_0_0". The device list
 // position came with Phase 7 and the notification count position with
-// Phase 8, each added at the end, which is what lets every token handed
-// out before them go on parsing. The leading "s" is there
+// Phase 8 and the typing position after them, each added at the end,
+// which is what lets every token handed out before them go on parsing. The leading "s" is there
 // to make a token recognisable in a log and to leave room for a second
 // token shape later — Simplified Sliding Sync (PLAN.md phase 10) has its
 // own — without any ambiguity about which is which.
@@ -42,10 +42,15 @@ type Token struct {
 
 	// Notification is the push server's notification count stream.
 	Notification int64
+
+	// Typing is the typing tracker's position. It lives in memory and
+	// starts again at zero when the server restarts, so it is compared
+	// for difference, never for order.
+	Typing int64
 }
 
 // tokenPositions is how many positions a token carries.
-const tokenPositions = 7
+const tokenPositions = 8
 
 // tokenPrefix marks a classic /sync token.
 const tokenPrefix = "s"
@@ -56,7 +61,7 @@ func (t Token) IsInitial() bool { return t == Token{} }
 
 // String renders the wire form.
 func (t Token) String() string {
-	parts := []int64{t.PDU, t.Receipt, t.ToDevice, t.AccountData, t.Presence, t.DeviceList, t.Notification}
+	parts := []int64{t.PDU, t.Receipt, t.ToDevice, t.AccountData, t.Presence, t.DeviceList, t.Notification, t.Typing}
 	// Trailing zeroes carry no information, and leaving them off keeps the
 	// common token short.
 	last := 0
@@ -123,6 +128,7 @@ func ParseToken(raw string) (Token, error) {
 		DeviceList:  positions[5],
 
 		Notification: positions[6],
+		Typing:       positions[7],
 	}, nil
 }