Phase 10: hardening and ops

Implements PLAN.md Phase 10.

Simplified Sliding Sync (MSC4186) is served at the unstable
org.matrix.simplified_msc3575 endpoint and advertised in /versions. Lists
are sorted by activity and filtered by DM, invite, encryption, room type,
space and tag; room subscriptions, required_state with wildcards, $ME and
$LAZY, and the to_device, e2ee, account_data, receipts and typing
extensions are supported. Per-connection state is kept in memory and an
unknown pos answers M_UNKNOWN_POS.

Threads and relations: m.relates_to is indexed on roomserver_events
(migration 0012), /relations (with recursion) and /threads are served, and
every event a timeline read returns carries its m.thread, m.replace and
m.reference summaries in unsigned.m.relations. Notifications carry a
thread ID (migration 0013): threaded receipts clear only their thread, and
sync reports unread_thread_notifications when the filter asks.

Spaces: /hierarchy walks a space breadth first, asking other servers about
rooms this one is not in through the new federation hierarchy endpoint;
room_summary describes one room. /search runs on FTS5 (sqlite, pocketbase)
or tsvector (postgres), bounded to what each user may see, with context,
profiles, state, grouping and paging.

The PocketBase driver is real: the sqlite schema and store on an embedded
PocketBase app's database, with media in its filesystem, local or S3
(database.pocketbase.s3). It runs the full storage test suite.

Ops: OpenTelemetry tracing over OTLP/HTTP (tracing.*), with server spans
per route, component spans, and trace propagation on federation, push and
application service calls. New metrics for persisted events, waiting
syncs, sliding sync connections and the database pool, with a Grafana
dashboard. deploy/ adds a Compose setup (PostgreSQL, Prometheus, Grafana,
Jaeger) and a Helm chart; cmd/warp-loadtest loads a server and reports
request and delivery latencies.

The load tester found a long-standing bug, fixed here: on a server where
no account data had been written, every incremental /sync re-sent the push
rules and returned at once, and an all-zero token was taken for an initial
sync, so long polls became busy loops.

The PostgreSQL migrations and search dialect compile but were not run
against a live PostgreSQL in this change.

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

server/internal/storage/sqlite/migrations/0013_thread_notifications.sql

@@ -0,0 +1,21 @@
+-- Phase 10: notifications counted per thread.
+--
+-- thread_id is the thread an event that notified a user belongs to: the
+-- root its m.relates_to names when rel_type is m.thread, and '' for an
+-- event on the main timeline. A read receipt for a thread clears that
+-- thread's rows and a receipt for the main timeline clears the '' rows,
+-- which is what lets reading one thread leave the rest of the room unread.
+ALTER TABLE push_notifications ADD COLUMN thread_id TEXT NOT NULL DEFAULT '';
+
+-- The notifications already stored, from the relation 0012 projected onto
+-- their events. A notification whose event has gone stays on the main
+-- timeline, where an unthreaded or main receipt still clears it.
+UPDATE push_notifications SET thread_id = COALESCE((
+    SELECT e.relates_to_id FROM roomserver_events e
+    WHERE e.event_id = push_notifications.event_id AND e.rel_type = 'm.thread'
+), '');
+
+-- A threaded receipt marks one thread's rows read; the per-thread counts a
+-- sync asks for group a room's unread rows by thread.
+CREATE INDEX IF NOT EXISTS push_notifications_thread_idx
+    ON push_notifications (user_id, room_id, thread_id, is_read, event_pos);