Use magda-io/wal-g fork build with PG15+ base backup protocol fix

[t83714]

Why

PostgreSQL 15 changed the BASE_BACKUP replication protocol. Every upstream wal-g release (1.1.0 – 3.0.8) fails backup-push against PostgreSQL 15+ in remote mode — the mode Magda's backup CronJob uses (backup-push with no $PGDATA argument).

Measured against PostgreSQL 17.5, with postgres:13.7 as a control:

wal-g	vs PG 17.5 (remote)	vs PG 13.7
3.0.8 / 3.0.7 / 3.0.6	CompressAndEncrypt: compression failed: archive/tar: invalid tar header	OK
3.0.5 / 2.0.1 / 1.1.0	42601 syntax error … repl_scanner.l	OK

Upstream issues: wal-g/wal-g#2044, wal-g/wal-g#1385 ("backup-push does not work on the Postgresql 15/16 without $PGDATA in command line"), wal-g/wal-g#2005.

The fix is wal-g/wal-g#2262, merged upstream 2026-05-22 — four months after v3.0.8 (2026-01-21). No upstream release contains it, and upstream's cadence is irregular (3.0.7 Apr 2024, 3.0.5 Jan 2025, 3.0.8 Jan 2026).

This blocks Magda's PostgreSQL 13.7 → 17.5 upgrade: without it, PG17 would ship with no working base backups.

What changed

• WALG_VERSION → 3.0.8-magda-edcda8b
• New WALG_REPO ARG, defaulting to magda-io/wal-g, so the source repo is a one-line override rather than an edit
• Refreshed the stale glibc comment — the binary is now copied into a Debian 12 bookworm image, not Debian 11

The fork release publishes artifacts in upstream's own layout (wal-g-pg-20.04-{amd64,aarch64}.tar.gz + .sha256), so the download-and-verify logic is untouched. Built on Ubuntu 20.04 / glibc 2.31, matching upstream, keeping it runnable on this image's bullseye base.

Release: https://github.com/magda-io/wal-g/releases/tag/v3.0.8-magda-edcda8b (master@edcda8bb, which has 9bcccbd — PR #2262 — as an ancestor)

Verification

Before publishing the fork release:

• backup-push (remote mode) against PG 17.5 → backup-list → backup-fetch → server start on restored data → all 5000 seeded rows returned intact
• No regression against PG 13.7 — required, since PG13 instances must keep being backed up during the migration window
• Extraction + sha256sum -c verified on a minideb:bullseye (glibc 2.31) base
• Max glibc symbol: GLIBC_2.3.4 (amd64), GLIBC_2.17 (aarch64)

After this Dockerfile change, both platforms were built locally from the published release:

$ docker run --rm --entrypoint /usr/local/bin/wal-g magda-wal-g-verify:arm64 --version
wal-g version v3.0.8-magda-edcda8b	edcda8bb	PostgreSQL

$ docker run --rm --platform linux/amd64 --entrypoint /usr/local/bin/wal-g magda-wal-g-verify:amd64 --version
wal-g version v3.0.8-magda-edcda8b	edcda8bb	PostgreSQL

Releasing

package.json stays at 3.0.8 — check-release-version.js compares only the part before the first -, so a release tagged v3.0.8-magda-edcda8b passes unchanged. release.yml will tag the image ghcr.io/magda-io/magda-wal-g:3.0.8-magda-edcda8b and correctly not move :latest, since the version contains a -.

Revert path

Set WALG_REPO=wal-g/wal-g and WALG_VERSION to an upstream release once one includes PR #2262.