0.13.2

A patch release with one distribution defect and eight merged fixes behind it. The distribution
defect is the reason it exists: the Linux desktop download could not start at all on an older
distribution, and nothing in the release pipeline could see that.

The Linux desktop AppImage could not start on an older distribution

An AppImage inherits the glibc of the machine that built it, and that dependency only ever
points one way. The x64 desktop job built on ubuntu-latest, so the released artifact required
GLIBC_2.38 in every bundled GTK and WebKit library and GLIBC_2.39 in the shell binary. Measured
against Ubuntu 22.04 (glibc 2.35, the oldest still-supported LTS), the loader refused every
bundled shared object:

libglib-2.0.so.0:       version `GLIBC_2.38' not found
libgtk-3.so.0:          version `GLIBC_2.38' not found
libwebkit2gtk-4.1.so.0: version `GLIBC_2.38' not found

There was no window, no log and no error message beyond that line. Anyone on Ubuntu 22.04,
Debian 12 or an enterprise distribution of the same generation downloaded a file that did
nothing.

No gate could catch it. The artifact built, was attested, uploaded, and ran on the runner and on
any recent desktop - the machine that would have noticed is not in the pipeline. So the x64
build is now pinned to ubuntu-22.04, a unit test refuses a floating runner label on that job,
and the pull-request AppImage smoke build is pinned to the same image, because an AppImage built
on a newer image than the release uses proves nothing about the artifact users download.

The arm64 AppImage still carries the same floor and is tracked as REL2 in docs/BACKLOG.md; it
needs its own runner-label dispatch run before a release commit touches it.

If you downloaded the AppImage and it never opened, this is the release to try.

MariaDB is named as MariaDB

getOverview() returned MySQL ${version} unconditionally, so a MariaDB server answering
12.3.2-MariaDB-ubu2404 was published as "MySQL 12.3.2-MariaDB-ubu2404" - an assertion the
server never made, and the first thing a MariaDB user saw. Found by connecting MariaDB 12.3 and
MySQL 26.7 side by side. The same PR removes a cache hit ratio that was reported as 99% without
being measured.

Trino returned every bigint past 2^53 rounded

A bigint arrives from the Trino client protocol as an unquoted JSON number, and JSON.parse
has no exact form for an integer wider than 2^53 - it rounds silently, with nothing to catch.
Measured against a live trinodb/trino:476.

The two routes that connect outside the caches never opened the SSH tunnel

The tunnel is opened by the two caching entry points only, so the routes that build a provider
directly and connect it went straight to the raw database host. Fixes #457, with the boundary
now pinned as a rule rather than as two more tests.

MongoDB: the ordinary deployment, authSource and distinct

The plain host/port MongoDB connection could not be connected to at all, authSource was not
carried, and distinct queries and their errors were handled wrongly. Each was measured against
a live server before the change and re-measured in a browser against a production build after
it.

The query agent reads foreign keys for the role we prescribe

The agent's foreign-key read came back empty under the least-privilege role the documentation
prescribes, because it queried a surface that role cannot see; it now reads pg_constraint.
Seven smaller agent and provider corrections ride along.

Eight engines showed BEGIN and answered HTTP 400

Transaction support was assumed rather than declared, so eight engines offered a transaction
control the engine rejects. Providers now declare it, along with reindex support, escaping and
CSV-injection handling.

Backlog sweeps

Four measured sweeps ran through this release. Each entry was verified against a live server
before it was touched, every change landed test-first, and coverage stays at 100 percent.

Helm chart: 0.1.46

No template change. Its content is the appVersion move to 0.13.2.

Full changelog: 0.13.1...0.13.2