fix(docker): pin Bun to 1.3.13; gate release on built image authenticating to PostgreSQL

[rhonda-rodododo]

Summary

A freshly built app image (oven/bun:1.4.2) could not authenticate to PostgreSQL on a clean host (PostgresError: malformed SCRAM message / Malformed proof in client-final-message.), so scripts/run-migrations.ts never ran and the container sat unhealthy. This PR (1) repins the runtime to the version proven on that host, (2) adds the missing check — the built image must authenticate to a real PostgreSQL and migrate — and makes it block CI and release, (3) makes the entrypoint fail loudly instead of hanging.

What I could and could not establish (read this)

I could not reproduce the SCRAM failure on my machine, so the exact version boundary is NOT bisected. Same bun -e query / postgres:17-alpine, 20 connections each, SCRAM stored (rolpassword = SCRAM-SHA-256$…):

Bun image	result
1.3.5, 1.3.13, 1.4.0, 1.4.1, 1.4.2	all OK
1.4.2 image, apt-get upgrade layer, non-root, --read-only	OK
1.4.2, passwords of length 20/43/63/64/65/100/128, url-safe charset	OK
1.4.2 vs 1.3.13, server scram_iterations 1…600000	OK (except iter=1 on 1.4.2: Failed to read data, different error)
1.3.13 and 1.4.2 under qemu-user -cpu Nehalem / max	OK
real deploy/docker/Dockerfile app image built from origin/main (Bun 1.4.2) → new verify script	OK — passes on my host

Only host-dependent difference found: the oven/bun 1.3.x x64 images ship the baseline build, 1.4.x ships the non-baseline build (Bun v1.3.14 (Linux x64 baseline) vs Bun v1.4.2 (Linux x64)). That is a hypothesis only. Note PostgreSQL emits "Malformed proof" when the proof does not base64-decode to 32 bytes — i.e. the client sent a malformed proof, not merely a wrong password — which points at the client's crypto/base64 path, not credentials. No newer Bun than 1.4.2 exists (latest release 1.4.2, 2026-09-05), so there is no fix to move forward to. The upstream SASLprep work (oven-sh/bun#41605) only affects non-ASCII passwords and is not this.

Pin: all three oven/bun stages → 1.3.13 (digest-pinned) — the version the reporter's A/B shows healthy on the failing host for months, and within the 1.3.x line CI already tests on (bun = 1.3.5). This is a rollback to known-good on that host, not a proven boundary. The Dockerfile comment records the error string and the conditions for lifting it.

The gate (the more important half)

• scripts/verify-image-db-auth.sh <image>: starts the compose file's pinned postgres:17-alpine on a private network with a random url-safe password (SCRAM asserted), runs the image's scripts/run-migrations.ts with a postgresql://llamenos:…@postgres:5432/llamenos URL, non-root/--read-only like the compose service, then asserts exit 0 and that the schema exists.
• ci.yml job image-db-auth (runs when backend paths change — deploy/docker/, drizzle/, apps/worker/, scripts/…) and is in ci-status.
• release.yml job image-db-auth, and release now needs it — so no GitHub Release is published, no downstream workflow dispatched, and docker-stable (needs release) does not push if the image can't migrate.
• deploy/docker/docker-entrypoint.sh: migration run is bounded (MIGRATION_TIMEOUT, default 180s) and exits 1 with a message. Previously a failed auth left the container looping silently.

Verify-by-breaking

• Real image built from this branch (Bun 1.3.13): OK: image authenticated … 101 public tables, exit 0.
• Same script against a simulated broken client (image whose bun wrapper corrupts the DB password, standing in for the SCRAM defect): PostgresError … ERR_POSTGRES_SERVER_ERROR → FAIL: migrations exited 1, script exit 1.
• I have no genuinely bad Bun image that fails on my hardware, so the honest statement is: the guard fails on an auth failure and passes on a good image; whether it would have caught 1.4.2 depends on the CI runner reproducing the fault. If the new CI job is green while a clean-host deploy still fails, the runner is not exposing the bug and a clean-host smoke test remains necessary.

Test plan

• bun test tests/orchestrator/{ci,release*}.test.ts tests/orchestrator/fragments.test.ts (121 pass)
• actionlint/shellcheck on changed files (only pre-existing findings elsewhere in ci.yml)
• docker build --target app + scripts/verify-image-db-auth.sh on pinned image
• image-db-auth job green in CI
• Deploy the rebuilt image to a clean host and confirm migrations run

No issue number was given/found for this, so no Closes line — please link one.

🤖 Generated with Claude Code

[rhonda-rodododo]

Superseded by #988.

This PR came from the first worker I dispatched, whose brief said to pin back to a known-good Bun. The operator's requirement is that we stay on the latest Bun SQL, so that worker was stopped and re-dispatched with a corrected brief — #988 (keep latest Bun working on CPUID-masked hosts) is the result.

The pin-back is also no longer warranted on the evidence: stock Bun 1.4.2 authenticates to PostgreSQL 17 correctly on any host exposing AVX2/SSE4.2. The SCRAM failure I originally reported reproduced only because my test VM ran without -cpu host, giving it qemu's default qemu64 model and forcing Bun's simdutf fallback path. A real VPS of this class exposes avx avx2 sse4_2.

The useful half of this PR — gating a release on the built image actually authenticating to PostgreSQL — is in scope for #988, which addresses the genuine narrow bug (the fallback path) without pinning back.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PPaW1Gu33GBWCKhEcNa2vz