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

README.md

@@ -529,10 +529,13 @@ Key settings in more detail:
 - `signing_key` — HMAC secret for URL signatures
 - `db_url` — the SQLite database to open; omitted, it is
   `file:<state_dir>/state.sqlite3?_pragma=journal_mode(WAL)`, which keeps the
-  database in WAL mode. pixa adds `_pragma=busy_timeout(5000)` to any `db_url`,
-  so a write that finds another in progress waits up to five seconds for it
-  instead of failing. WAL mode comes only from the URL: keep
-  `_pragma=journal_mode(WAL)` in one you set
+  database in WAL mode. pixa opens one connection to it, so its own reads and
+  writes run one at a time. Requests wait while eviction runs one of its
+  queries, some of which read a whole table. pixa adds
+  `_pragma=busy_timeout(5000)` to any `db_url`, so a write that finds another
+  program writing to the file waits up to five seconds for it instead of
+  failing. WAL mode comes only from the URL: keep `_pragma=journal_mode(WAL)` in
+  one you set
 - `cache_max_bytes` — disk cache size limit in bytes; `0` disables the disk
   cache entirely; omitted defaults to 75% of the sum of the free space on the
   filesystem containing `<state_dir>/cache/` and the bytes of source and