fix: reliability and performance sweep under load

[xsmyile]

Reliability and performance sweep, driven by load testing an SMTP catcher under the traffic it exists to receive.

Closes #50.

Four things a reviewer cannot infer from the diff:

Message ordering changed from ULID text to arrival order. list, search and trim_to_max now order by rowid. ULIDs only sort by time down to the millisecond — within one millisecond the random bits decide, so bursts were shuffled. This is what lets FTS5 return rowids in descending order natively, which is where the search speedup comes from (46k rows, query matching everything: 36 → 2019 req/s, p50 1364 → 23 ms). The exact total is preserved; the old search_count join into messages was a no-op on an external-content index and cost 13 ms.

New runtime dependency: @tanstack/solid-virtual (MIT, one transitive package, no further tail). solid-js was previously the only runtime dep. Six thousand received messages rendered 90k DOM nodes and held 112 MB — measurement showed only 2.9 MB of that is the message data, the rest is markup. Windowing brings it to 343 nodes and 6 MB with every row still reachable. Bundle cost: +10 KB gzip.

The raw endpoint takes ?limit=<bytes>, not a Range header. CompressionLayer compresses 206 responses too, which would leave Content-Range describing the uncompressed bytes while the body is gzip — incorrect per RFC 9110. The alternatives were excluding message/rfc822 from compression (losing gzip on .eml downloads) or adding http-body as a direct dependency for a predicate. The query parameter keeps compression and stays correct. Documented in docs/api.yaml.

No parallel message processor, deliberately. The single-task insert loop is still the ingest ceiling, but SQLite allows one writer per database: measured 453 insert/s with one writer and 550 with eight, so a worker pool buys ~21% while making WebSocket event order nondeterministic. CPU per 1.37 MB message is down 14.3 → 6.0 ms; throughput is unchanged and disk-bound. The remaining lever is the 1.73× storage amplification — attachments.content re-stores decoded what the raw blob already holds in base64 — which is a schema change and out of scope here.

Also fixed under load: a client reusing one connection was disconnected after 333 messages (the command cap counted every command, not just unproductive ones), and a WebSocket client that fell behind was served the surviving events and left connected, so its inbox stayed silently wrong.

140 tests, clippy clean, every commit builds in isolation.

[xsmyile]

Review of the previously unreviewed commits found one Medium worth fixing here, now done in 573b96c: removing the per-connection command cap had moved the binding limit on a bulk send to the 300s session timeout in `server.rs`, which dropped the socket mid-transaction with no reply. Every await inside a session already carries its own deadline — per-line I/O, the DATA phase, the STARTTLS handshake — so the blanket cap only ever cut off clients that were still delivering. It is gone, with a virtual-time test covering the silent-peer path.

Two Low items came along: a malformed `?limit=abc` now fails in the same JSON shape as an out-of-range one instead of falling through to the extractor default, and the websocket test helper reads 64-bit frame lengths.

The remaining review item is keyboard navigation into the virtualized list, filed separately as #52 — it is list-navigation work rather than part of this sweep.