fix(release): freeze linux binaries on ubuntu-22.04 to restore glibc 2.35 compatibility

[padak]

Why

A PyInstaller binary requires the build machine's glibc (or newer) at runtime, so the freeze runner sets the compatibility floor for every end user. The linux amd64 freeze leg runs on ubuntu-latest, which is 24.04 (glibc 2.39) — the v0.71.0 binary fails on any glibc < 2.38 system:

[PYI-2687:ERROR] Failed to load Python shared library '/tmp/_MEI188JGu/libpython3.12.so.1.0':
dlopen: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found

Caught by test-install's Homebrew (Linux) leg in the v0.71.0 release run (29752342509), which runs the binary inside the homebrew/brew image (Ubuntu 22.04-era glibc). The apt/rpm legs passed only because ubuntu:latest and fedora carry new-enough glibc. This is an end-user regression, not a CI quirk: Ubuntu 22.04 / Debian 12 systems cannot run the frozen binary at all. It was previously masked because the v0.66.1 Homebrew leg failed earlier on the missing brew trust step (fixed in #483).

What

Pin both linux freeze legs to the oldest GA runners — ubuntu-22.04 (amd64) and ubuntu-22.04-arm (arm64), glibc 2.35 — and document in the matrix why -latest must never be used for freeze legs. Both runner labels are GA per actions/runner-images (no deprecation scheduled).

Verification

• The released v0.71.0 linux binary demonstrably requires GLIBC_2.38 (release-run failure above).
• Workflow YAML validates; no other pipeline change.
• Full proof comes from the next release run's test-install Homebrew leg, which now exercises exactly the old-glibc scenario. A workflow_dispatch dry run of release-kbagent on this branch builds the binary on the pinned runners without publishing anything.

Relation to #503

Refs #503 — this is the "mechanical change" the issue describes (option A: pin to ubuntu-22.04, glibc 2.35 floor). It restores Ubuntu 22.04 LTS and Debian 12. It does not cover RHEL 9 / Amazon Linux 2023 (glibc 2.34) — if that class of distro should run the native binary, the freeze has to move into an older container (debian 11 / manylinux-style base), which is the floor decision #503 leaves to the maintainers. Keeping #503 open for that call is reasonable; this PR removes the immediate 2.38 regression either way.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[padak]

Post-merge verification of the glibc floor (local, full freeze-job replica):

Build — ubuntu:22.04 container (arm64, native), mirroring the freeze job: deadsnakes Python 3.12 (built on 22.04, same class as actions/setup-python's toolcache build), Node 20 for the SPA, uv build --wheel, PyInstaller 6.11.1 --onefile --collect-all keboola_agent_cli. Build succeeds; the bootloader ELF requires only GLIBC_2.17 (PyInstaller ships manylinux bootloaders).

Run — the produced binary executed in a clean ubuntu:22.04.5 container (glibc 2.35, no Python, env -i):

$ env -i /out/kbagent --version
kbagent v0.71.0

This is the exact scenario where the released v0.71.0 amd64 binary died with GLIBC_2.38 not found (the homebrew/brew image is 22.04-based). A 22.04-built binary runs there fine, confirming the pinned runners restore the 2.35 floor. The verification build is arm64 (native on the test machine); the glibc-floor mechanism is architecture-independent and both linux legs are pinned by this PR. Full end-to-end proof lands with the next release run's test-install Homebrew leg (or a workflow_dispatch dry run from main).