v2026.09.22 — the image takes libsqlite3-0 deb13u2

The image takes Debian's libsqlite3-0 security update (PR #31).

v2026.09.21's image carried libsqlite3-0 3.46.1-7+deb13u1. Its base, python:3.12-slim of 2026-09-01, had not picked up Debian's 3.46.1-7+deb13u2 (2026-06-14), which backports two fixes in FTS5, the full-text engine search is built on:

• CVE-2026-11822: memory corruption in FTS5;
• CVE-2026-11824: a heap-based buffer overflow in FTS5.

A rebuild alone does not take the fix, because the Dockerfile used the base as it is.

What changes: one RUN in the Dockerfile's final stage upgrades libsqlite3-0 alone, unpinned: a pinned version leaves Debian's mirror at the next update and would break the build. SQLite stays 3.46.1. There is no code change, no schema change and no migration.

Not a migrating release. Deployed as routine: set DY_TAG, pull, bring up. Schema stays 29.

Verified before merge:

• Local build: libsqlite3-0 deb13u1 → deb13u2.
• The suite inside the built image, against its installed code: 853 passed, 1 skipped.
• CI green; Codex code and security reviews: no findings.

Deployed 2026-09-14 10:04–10:05 UTC, routine (no wall). DY_TAG v2026.09.22; /health reports v2026.09.22, schema 29. Both the web and ingest containers carry libsqlite3-0 3.46.1-7+deb13u2, and SQLite reports 3.46.1. Every service is running and web is healthy; the poller captured at 10:05:17 UTC. /, a search, a docket sheet and /methodology return 200.

The operator's decision, 2026-09-13. Moving past SQLite 3.46 (the WAL-reset fix, 3.53's ALTER for constraints) stays its own later decision: docs/deferred.md § SQLite 3.53.4.