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

* fix(docker): register /usr/local/lib in ld.so.conf.d so the source-built SQLite loads on arm64

The #6900 SQLite-from-source upgrade passed the amd64 docker-smoke but FAILED the
multi-arch release build on linux/arm64 with '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 picked up on amd64). Register /usr/local/lib via an
ld.so.conf.d entry before ldconfig so the new lib wins on every architecture.

The PR's own build-time version assertion is what surfaced this (correctly), and
it also serves as the verification that the fix works once the arm64 build passes.

Follow-up to #6900 (exp-v0.52.227, whose multi-arch image failed to build/push).

* test-fix: keep wal.html link within 500 chars of ARG (condense arm64 comment)

---------

Co-authored-by: nesquena-hermes <agent@nesquena-hermes>

Dockerfile

@@ -36,7 +36,7 @@ RUN apt-get update -y --fix-missing --no-install-recommends \
 # https://sqlite.org/wal.html#walresetbug
 #
 # Debian has not backported the fix, so we compile from the amalgamation.
-# Installs to /usr/local/lib (takes ldconfig priority over /usr/lib).
+# Installs to /usr/local/lib (registered in ld.so.conf.d for arm64 priority).
 # Build tools are purged after compilation to keep the image lean.
 # Build args are for forward version bumps only (3.54+, etc.).
 # When bumping SQLITE_VERSION, recompute the SHA-256 from the official
@@ -56,6 +56,7 @@ RUN apt-get update \
        --enable-fts5 --enable-fts4 --enable-rtree \
     && make -j"$(nproc)" \
     && make install \
+    && echo "/usr/local/lib" > /etc/ld.so.conf.d/000-usr-local-lib.conf \
     && /sbin/ldconfig \
     && cd / && rm -rf /tmp/sqlite* \
     && apt-get purge -y gcc make libc6-dev \