Queue SQLite writes on one connection so none fails as locked (closes #223)

internal/database now opens the database with one connection. pixa's
own reads and writes run on it one at a time instead of competing for
SQLite's lock, where a write that kept losing could wait past the
five-second busy timeout and fail with "database is locked". The busy
timeout stays, for another program writing to the same file.

With one connection, a query run while rows or a transaction are still
open would wait forever. No code in internal/database or
internal/imgcache does that; the comment on DB() tells callers.
README.md says pixa uses one connection and that requests wait while
eviction runs one of its queries.

Model: opus-5-5

TODO.md

@@ -30,6 +30,13 @@ P2: security: per-IP rate limiting on the image routes
 
 # Completed Steps
 
+- 2026-10-08 SQLite writes no longer fail with "database is locked" under load
+  (closes #223): `internal/database` opens the database with one connection, so
+  pixa's own reads and writes run on it one at a time instead of competing for
+  SQLite's lock, where a write that kept losing could wait past the five-second
+  busy timeout and be lost. The busy timeout stays, for another program writing
+  to the same file. No code in pixa keeps rows or a transaction open while it
+  runs another query, which with one connection would wait forever.
 - 2026-10-05 the format `auto` (closes #88): a format in the `/v1/image/` path,
   an encrypted URL's token and the generator page's format choice, chosen for
   each request from `Accept` once the signature or token is checked: AVIF when