Release: SQLite arm64 loader fix (exp-v0.52.228)

[nesquena-hermes]

CHANGELOG note for #7044 (arm64 ld.so.conf.d fix), merged in 6086446. Makes #6900's SQLite-from-source image actually build+load on arm64 (exp-v0.52.227's multi-arch image failed on arm64). Tagging exp-v0.52.228 and watching the multi-arch Release build to completion.

[greptile-apps]

Greptile Summary

This release PR expands the SQLite changelog entry to document the ld.so.conf.d fix that makes the source-built library take precedence on arm64.

• Records that the source-built SQLite library is registered with the dynamic loader.
• Associates the release note with the arm64 loader fix in fix(docker): source-built SQLite must load on arm64 (ld.so.conf.d) — follow-up to #6900 #7044.
• Contains a minor factual imprecision about the underlying loader-path behavior.

Confidence Score: 4/5

The PR appears safe to merge, with only a non-blocking wording correction recommended for the arm64 loader explanation.

The documented fix and release behavior are supported, but the changelog should describe library search precedence rather than claiming /usr/local/lib is absent from the default path.

Files Needing Attention: CHANGELOG.md

Important Files Changed

Filename	Overview
CHANGELOG.md	Documents the arm64 SQLite loader-order fix accurately in outcome, but imprecisely describes /usr/local/lib as absent from the default loader path.

_{Reviews (1): Last reviewed commit: "Release: SQLite source build loads on ar..." | Re-trigger Greptile}

[greptile-apps]

Correct the arm64 loader explanation

Debian includes /usr/local/lib through ld.so.conf.d; the arm64 issue is that the multiarch library directory takes precedence. Describing this as a search-order conflict gives operators an accurate diagnostic model while preserving the documented outcome.

Suggested change

- **Docker: the bundled SQLite is upgraded to 3.53.0 to fix a WAL-reset corruption bug (and still erases deleted rows).** The `python:3.12-slim` base image ships SQLite 3.46.1, which is vulnerable to the March 2026 WAL-reset corruption bug, and Debian hasn't backported the fix — so the image now compiles SQLite 3.53.0 from the official amalgamation (SHA-256 pinned and verified before extraction, FTS5/FTS4/R-Tree enabled, build tools purged afterward). The source build is also compiled with `SQLITE_SECURE_DELETE` and asserts `PRAGMA secure_delete = 1` at build time, so deleting a conversation still overwrites its content on disk exactly as the base image did (a from-source build without that flag would have left deleted transcript bytes recoverable in `state.db`). Only affects the Docker image. The source-built library is registered in `ld.so.conf.d` so it loads ahead of the base image's copy on every architecture (including arm64, where `/usr/local/lib` isn't on the default loader path). Thanks @qxxaa. (#6900, #7044)

- **Docker: the bundled SQLite is upgraded to 3.53.0 to fix a WAL-reset corruption bug (and still erases deleted rows).** The `python:3.12-slim` base image ships SQLite 3.46.1, which is vulnerable to the March 2026 WAL-reset corruption bug, and Debian hasn't backported the fix — so the image now compiles SQLite 3.53.0 from the official amalgamation (SHA-256 pinned and verified before extraction, FTS5/FTS4/R-Tree enabled, build tools purged afterward). The source build is also compiled with `SQLITE_SECURE_DELETE` and asserts `PRAGMA secure_delete = 1` at build time, so deleting a conversation still overwrites its content on disk exactly as the base image did (a from-source build without that flag would have left deleted transcript bytes recoverable in `state.db`). Only affects the Docker image. The source-built library is registered in `ld.so.conf.d` so it loads ahead of the base image's copy on every architecture (including arm64, where multiarch library paths take precedence over `/usr/local/lib` by default). Thanks @qxxaa. (#6900, #7044)

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!