`cre update` installs a glibc-2.38 binary on glibc-2.36 hosts and bricks the CLI (an `_ldd2-35` asset exists but is never selected)

cre update unconditionally downloads the cre_linux_amd64 release asset, which is
built against GLIBC 2.38. On any Linux host with an older glibc — Debian 12
(2.36), Ubuntu 22.04 (2.35), RHEL 9 (2.34) — the freshly installed binary cannot
execute at all. Because cre update overwrites the existing binary in place with
no backup, this leaves the user with no working cre command and no obvious
path back.

The releases already ship a compatible cre_linux_amd64_ldd2-35 asset.
cre update just never chooses it.

Environment

Steps to reproduce

1. On a host with glibc < 2.38, install the CRE CLI.
2. Run cre update.
3. Run any cre command.

Actual behaviour

cre update reports success:

Checking for updates...
! Could not compare versions (current: 'development', latest: 'v1.31.0'). Proceeding with update.
Updating...
Extracting...
✓ CRE CLI updated to v1.31.0

cre: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by cre)
cre: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by cre)
! Failed to verify version: exit status 1

Every subsequent invocation then fails the same way:

$ cre version
cre: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.38' not found (required by cre)
cre: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by cre)

Note that ✓ CRE CLI updated to v1.31.0 is printed before the failure, so the
update reads as successful on a quick skim.

Expected behaviour

cre update should detect the host's glibc version and select the
cre_linux_amd64_ldd2-35 asset when the default build is incompatible — or, at
minimum, verify the new binary runs before replacing the old one, and roll back
if it does not.

Workaround

Download the compatible asset manually and replace the binary:

curl -sL -o cre.tar.gz \
  https://github.com/smartcontractkit/cre-cli/releases/download/v1.31.0/cre_linux_amd64_ldd2-35.tar.gz
tar xzf cre.tar.gz
./cre_v1.31.0_linux_amd64 version     # verify BEFORE installing
cp cre_v1.31.0_linux_amd64 ~/.cre/bin/cre && chmod +x ~/.cre/bin/cre

This restores a working v1.31.0. Existing credentials in ~/.cre/context.yaml
survive the swap — cre whoami still authenticates afterwards.

Suggested fixes, roughly in order of value

1. Back up the current binary before replacing it, and restore it if the new
   one fails its version check. This alone turns a bricked CLI into a no-op.
2. Select the asset by host glibc. ldd --version or a link-time check against
   the ELF's GLIBC_* version needs is enough to pick _ldd2-35.
3. Verify before replacing, not after — the current order guarantees the
   failure mode.
4. If neither is feasible, fail loudly with the workaround in the error text,
   naming the _ldd2-35 asset. As it stands the error mentions only the missing
   symbol, and nothing points to the compatible download.

Impact

Hits anyone on a stable/LTS distro. Debian 12 and Ubuntu 22.04 are both common
CI-runner and dev-VM baselines, so this is likely to show up in automated
environments as well as on laptops — and in a workshop or bootcamp setting it
takes an attendee fully offline mid-session, since the recovery is not
discoverable from the error message.

Start with the cre update entry point and trace how it selects and replaces release assets. Reproduce on a host below glibc 2.38, then verify that the compatible _ldd2-35 asset is selected or that the new binary is checked before replacement and rolled back on failure.