Phase 2: the event core

Implements PLAN.md Phase 2: the library every later phase is built on,
as pure code under server/internal/matrix with no HTTP and no storage.

canonicaljson: the canonical JSON encoding, hand-written because
encoding/json escapes <, > and & and accepts floats. Integers only, in
[-(2^53)+1, 2^53-1]; lone surrogate escapes rejected rather than turned
into U+FFFD.

signing: the Signing JSON algorithm alongside the existing key handling,
and one lenient base64 decoder shared by the packages above it.

id: identifier grammars as they appear inside events, deliberately laxer
than userapi's account rules because rooms carry historical user IDs.

roomversion: the registry. Versions 3 to 12 are supported, each written
out in full as a Rules value with the flags the other packages read.
Versions 1 and 2 are known but refused: their event format and state
resolution v1 wait for federation. createRoom will default to 11, as the
spec asks for a while after 1.16, with 12 available.

event: PDU parsing and validation, content and reference hashes, event
IDs, the redaction algorithm for every supported version, signing and
verification, and a Builder.

auth: the authorisation rules in spec order, power levels with their
defaults, v12 creators with infinite power, the auth events selection
algorithm, rule 3's auth_events checks, and the separate test for
whether a redaction applies. Comments use the room version 12 rule
numbering, with the version 11 numbers given where they differ.

stateres: state resolution v2, and version 12's amendment (an empty
starting state and the conflicted state subgraph).

Tested against the spec's own vectors byte for byte: the canonical JSON
examples, both JSON signing vectors and both event signing vectors.
State resolution ports scenarios from Synapse's suite. canonicaljson
and event.Parse have fuzz targets.

The capabilities endpoint now advertises the registry instead of a
hard-coded "11". docs/event-core.md describes the packages and the
known gaps.

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

server/internal/clientapi/capabilities.go

@@ -4,15 +4,29 @@ import (
 	"net/http"
 
 	"github.com/dariuszjaniak/warp/server/internal/httputil"
+	"github.com/dariuszjaniak/warp/server/internal/matrix/roomversion"
 	"github.com/dariuszjaniak/warp/server/internal/userapi"
 )
 
-// DefaultRoomVersion is what this server creates rooms at.
+// DefaultRoomVersion is what this server creates rooms at. The room
+// version registry decides which one that is, and why.
+const DefaultRoomVersion = string(roomversion.Default)
+
+// availableRoomVersions is the m.room_versions.available map.
 //
-// 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"
+// Every version Warp implements is marked stable, because every version
+// the spec still lists is stable — the "unstable" marking is for versions
+// under development, which we do not implement. Versions 1 and 2 are in
+// the registry but not supported, and so are left out: a client offered a
+// version it cannot be given would get an error on createRoom.
+func availableRoomVersions() map[string]string {
+	supported := roomversion.Supported()
+	out := make(map[string]string, len(supported))
+	for _, v := range supported {
+		out[string(v)] = "stable"
+	}
+	return out
+}
 
 // roomVersionsCapability is the m.room_versions capability.
 type roomVersionsCapability struct {
@@ -52,7 +66,7 @@ func (c *ClientAPI) handleCapabilities(w http.ResponseWriter, _ *http.Request, _
 		Capabilities: capabilities{
 			RoomVersions: roomVersionsCapability{
 				Default:   DefaultRoomVersion,
-				Available: map[string]string{DefaultRoomVersion: "stable"},
+				Available: availableRoomVersions(),
 			},
 			ChangePassword:  booleanCapability{Enabled: false},
 			SetDisplayName:  booleanCapability{Enabled: true},