Fix GLIBC mismatch, and make the release prove the container boots

[WaylandYang]

The failure

The published image pulled and started, then exited immediately:

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

rust:1-slim tracks upstream and is on trixie now (glibc 2.41). The runtime stage is debian:bookworm-slim (glibc 2.36). The binary linked against a newer libc than the image it ships in.

Pinning the build stage to rust:1-slim-bookworm ties both ends to one distro, and keeps a future upstream bump from silently reopening the same gap.

Why CI could not have caught it

It builds clean. Publishing succeeded. Every signal was green — the image simply cannot start. The gap between "builds" and "runs" had nothing covering it.

So the release now loads the image and runs it against a real Postgres before publishing, asserting:

1. /api/v1/health returns {"status":"ok"} — process alive, migrations applied
2. POST /api/v1/auth/register returns 200 with a token — argon2 hashing and JWT issuance work end to end (the path that would have caught the rust_crypto panic in Fix auth-bypass advisory in jsonwebtoken (CVE-2026-25537) #23)

Only then does it push.

Health is checked at the nested path with a body assertion on purpose: the image serves an SPA fallback, so a request to /health returns 200 with index.html. Checking that would have passed while proving nothing.

Polling conditions are written as if, not cmd && break — under set -e the latter aborts the run the first time a service is not ready yet.