Real-server evidence for slow SQLite writes

Environment: Linux, Node 26.12.1, Chromium web client at 1280x800, dark diagnostic overlay, fresh synthetic databases; no user database copied.
Base: 7bf2a43c09855965bf740f2f204809a2075bc807
Head: 21a446ff06ef092567ec48588ca906ef6f2df527

Run driver.py before/after from scratch beside installed base/head checkouts. It initializes a fresh server, stops it, restarts under strace -f with path filters for statev2.sqlite and its WAL, injecting pwrite64:delay_enter=3s:when=150+150. It creates one synthetic project through the CLI. After its go marker is created, it dispatches 1200 independent HTTP probes every 50ms, with a 5s socket timeout, and launches 3 showcase Replay threads at t=2s. A separate connected browser uses monitor.js (replace SIDE and SHA) to show live 20Hz HTTP probes with a 5s abort timeout. Record its screen. Touch finish to stop the server.

Videos capture live diagnostic overlays in the authenticated real app; they do not show chat rendering. Base recording starts before workload; head recording starts approximately 7 seconds into workload and continues through it. HTTP JSON samples cover the complete identical 60-second workload on each side. The 40-second video frames are illustrative video frames, not static-rendering proof.

Expected difference observed: main-thread delayed writes and HTTP timeouts on base; worker-thread delayed writes and uninterrupted HTTP on head. Base records event-loop stalls; head records none. PIDs in thread-mapping.json were checked against the actual listening server and /proc thread names.

Limit: all three threads were launched, but turn completion is not claimed. The three concurrent CLI processes on head logged database-is-locked errors while revoking their temporary auth sessions (they also open the database). Those error summaries are supplied. Keepalive latency and remote/relay disconnect prevention were not separately measured.

Privacy: syscall buffer contents and absolute database paths were redacted; runtime excerpts include observed stalls and JSON thread-launch results only. No tokens, machine labels or user data are included.
