Keep the store's one connection, delete the seam it cannot survive (V-642)

`SetMaxOpenConns(1)` under WAL gives up concurrent reads, and the task
asked whether that costs anything. Measured over a fixed two-second
window, a paced writer against a read loop, three runs per cap:
reads do not queue. Four connections buy 70µs at p50 on a turn that
spends 1.19s in the resident model, and write throughput more than
halves. A 19ms worst case also cannot be the source of the 2.7s router
figure, so that line of enquiry is closed.

What the cap cannot survive is a long-lived transaction. It holds the
only connection, so a second read never completes: two seconds and
`context deadline exceeded`, against 1ms at a cap of four.

`Store.DB` handed out exactly that transaction. It had been there since
the initial commit with no production caller, and its comment described
a loop that never materialised. Its one user was a test helper reading
`delivery_attempts` by raw SQL, which `ListDeliveryAttempts` has covered
since V-390. So the cap stays and the seam goes, and the hazard is gone
by construction rather than by documentation.

`internal/store/conncap_test.go` stays as the standing measurement,
skipped under -short. The comment at the cap and the one in
`internal/ipc/server.go` that leans on it now state the invariant and
cite the numbers.

Measurement: docs/evals/2026-08-07-store-connection-cap.md

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

internal/ipc/server.go

@@ -17,9 +17,11 @@ import (
 // Server — the core side of the boundary. Listens on a unix domain socket,
 // accepts module connections, frames requests to a CoreAPI and responses back.
 // One Server per daemon process; concurrent connections are handled in their
-// own goroutine but share the single CoreAPI (and therefore the single store
-// writer — store is single-connection, SetMaxOpenConns(1), so serialization is
-// already guaranteed at the db; the Server adds no locking of its own).
+// own goroutine but share the single CoreAPI, and so the single store writer.
+// The store opens at SetMaxOpenConns(1), so serialisation is already guaranteed
+// at the database and the Server adds no locking of its own. That cap is an
+// invariant this comment depends on, measured and kept on 07-08-2026 (V-642,
+// docs/evals/2026-08-07-store-connection-cap.md).
 type Server struct {
 	api  atomic.Value // stores CoreAPI
 	path string