fix(docker): source-built SQLite must load on arm64 (ld.so.conf.d) — follow-up to #6900

[nesquena-hermes]

The problem

#6900 (exp-v0.52.227) compiles SQLite 3.53.0 from source. The amd64 docker-smoke passed, but the multi-arch Release build failed on linux/arm64:

AssertionError: SQLite 3.46.1 still vulnerable

Python's sqlite3 kept loading the base image's /usr/lib multiarch libsqlite3 (3.46.1) instead of the freshly-compiled /usr/local/lib copy (3.53.0), because /usr/local/lib is not in the default ld.so search path on Debian arm64 (it happened to be found on amd64). So the release image failed to build/push — no broken image shipped (the PR's own build-time version assertion correctly fails-closed), but exp-v0.52.227 has no Docker image.

The fix

Register /usr/local/lib in /etc/ld.so.conf.d/ before ldconfig, so the source-built SQLite wins on every architecture. The PR's build-time >= 3.51.3 + PRAGMA secure_delete == 1 assertions verify correctness once the arm64 build runs.

Verification

amd64 docker-smoke runs on this PR. The multi-arch (amd64+arm64) build only runs on a release tag — so the authoritative verification is watching the Release & Docker workflow on the follow-up tag (exp-v0.52.228).

[greptile-apps]

Greptile Summary

The PR registers /usr/local/lib with the dynamic linker before running ldconfig, ensuring the source-built SQLite library takes precedence in arm64 images.

• Adds an early-sorting ld.so.conf.d entry for /usr/local/lib.
• Updates the adjacent SQLite installation comment.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
Dockerfile	Adds dynamic-linker configuration so Python resolves the source-built SQLite library consistently across image architectures.

_{Reviews (2): Last reviewed commit: "test-fix: keep wal.html link within 500 ..." | Re-trigger Greptile}

[greptile-apps]

Correct the arm64 linker explanation

Debian arm64 includes /usr/local/lib through libc.conf; the problem is that the multiarch configuration sorts earlier and takes precedence. Describing the path as absent obscures the ordering issue that the 000- filename fixes.

Suggested change

	# /usr/lib multiarch copy (the default ld.so path does NOT include
	# /usr/local/lib on Debian arm64, so the explicit conf entry is required).
	# /usr/lib multiarch copy (`aarch64-linux-gnu.conf` sorts before Debian's
	# `libc.conf`, so this earlier explicit entry is required).

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!

[nesquena-hermes]

Verified in exp-v0.52.228: the multi-arch Release & Docker build (amd64 + arm64) completed successfully and pushed the image. The arm64 build passed the source-SQLite version assertion (>= 3.51.3) and the PRAGMA secure_delete == 1 assertion, confirming the ld.so.conf.d registration makes Python load the freshly-compiled /usr/local/lib SQLite on arm64. #6900's WAL-reset fix now ships on both architectures.