…td -19 --long=31

Two changes, bundled:

1. Split the single mega-job into three phases so failures are legible and
   no job holds both powers:
   - preflight (ubuntu-latest): computes the dump filename and release tag
     ONCE as job outputs (per-job date stamping could straddle midnight UTC
     and split a run across two dates); fails fast if the tag already exists.
   - dump (blacksmith-32vcpu): holds only the DB credential, no repo write.
     Keeps pg_dump | zstd | split as one streaming step -- a job boundary
     between dump and compress would force uploading and re-downloading the
     full uncompressed database (tens of GB) as an artifact. Adds a
     post-compress `zstd -t` integrity pass, a SHA256SUMS, and a forensics
     header (nproc/free/df).
   - release (ubuntu-latest): holds only contents:write, no DB credential.
     Verifies checksums, creates the release with SHA256SUMS attached.

2. Fix the failing weekly run (#29166233752) and pick the compressor from a
   benchmark on a real 3 GiB dump sample (ratios conservative -- the sample
   loses cross-region matches the contiguous stream has):
     zstd -12 --long=27  24.4x @ 377 MiB/s   (too weak)
     zstd -19 --long=31  36.7x @  27 MiB/s   <- chosen
     xz -9e dict=192MiB  35.8x @   5 MiB/s   (old prod: worse ratio, 5x slower)
     zstd -22 --ultra    38.9x @   8 MiB/s   (+6% only, ~130 min -> times out)
   The old `xz -9e --dict=192MiB` ran near single-threaded (~5 MiB/s: 9e
   can't fill its 576 MiB blocks fast enough to parallelize on a pipe), so
   the dump ran for hours and the job was cancelled/timed out. zstd -19
   --long=31 beats it on ratio, runs ~5x faster (~40 min on ~60 GB, well
   under the 120 min timeout), and uses a bounded window (no runaway memory).
   Restore docs updated to `zstd -d --long=31`.

A failed release is now re-runnable without repeating the dump.

The 32-vCPU/128-GB runner was sized for xz -9e's memory/thread appetite.
zstd -19 --long=31 uses a bounded ~2 GiB window (a few GiB total across
threads) and the pipeline is likely source-bound (pg_dump over the
network), so the monster runner is unnecessary. Drop to blacksmith-8vcpu;
the forensics header (nproc/free/df) and zstd -v rate on the first real
run confirm sizing and timeout headroom before downsizing further.

The smoke test (#29176304089) OOM-killed zstd on the 8 vCPU/30 GiB runner
when the large eval_samples table started streaming: broken pipe, exit 143,
~8.5 min in (not the timeout). Root cause: zstd's multithreaded memory
scales with windowSize x thread count, and --long=31's 2 GiB window across
8 -T0 workers exceeded 30 GiB at steady state. The ratio benchmark used a
3 GiB sample that never reached that high-water, so it measured ratio
correctly but missed the memory cost.

--long=27 (128 MiB window) keeps memory to a few GiB regardless of thread
count and still compresses ~32.4x (vs 36.7x for --long=31, 24.4x for the
old -12), while decompressing with plain `zstd -d` (<=27 is within zstd's
default decompressor limit). Reclaiming --long=31's ratio later means
capping threads or a high-memory runner; documented inline.

…p VM kill

Two smoke runs died mid-dump on a big-blob table (eval_samples,
benchmark_server_logs) with no OOM line and the VM terminated; --long=27
ruled out zstd as the memory hog. Add a 3s sampler logging total memory +
top-RSS processes so the next run's log shows the memory curve and the
owning process (likely pg_dump/libpq buffering a giant row). Temporary --
revert once the cause is confirmed.

…expand mem sampler

The instrumented run proved the memory hog is blacksmithd (the Blacksmith
runner daemon) at ~28 GiB, not the pipeline (pg_dump 75 MiB, zstd 1.5 GiB).
The 30 GiB 8-vCPU tier OOM-killed on the daemon; the historical 32-vCPU/
128 GiB runner had headroom, so this only broke after the downsize. Revert
to 32 vCPU. Blacksmith has no workflow toggle to disable the cache (support
ticket only), and the ~28 GiB daemon looks like a bug worth reporting.

zstd kept at --long=27 to isolate the runner fix (restore --long=31 for the
better ratio once green). Sampler expanded: mem+swap, tmpfs usage, top-RSS
processes with argv, plus a one-time blacksmithd dump.

…lls any VM)

Instrumentation is conclusive: blacksmithd (the Blacksmith runner daemon)
grows to consume the whole VM regardless of size -- ~28 GiB on a 30 GiB
runner, ~110 GiB on a 115 GiB runner -- then OOMs the box mid-dump. The
pipeline is tiny throughout (pg_dump 75 MiB, zstd 1.5 GiB). A bigger
Blacksmith VM can't fix it and the cache has no workflow-level disable, so
move the dump job to a github-hosted ubuntu-latest (no blacksmithd; the
<2 GiB job fits 16 GiB). timeout 120 -> 180 for the 4-core compress on a
growing DB. Instrumentation kept until this passes green.

Diagnosis complete (blacksmithd was the OOM cause; fixed by moving to
ubuntu-latest). Drop the forensics step and the per-3s memory sampler;
keep a trimmed comment recording why the job runs on a GitHub-hosted
runner and stays at zstd --long=27.

Remove the prose comments accumulated during debugging. Keep the inline
permission-scope notes (contents: read/write), the two pinned-action
version tags, and a shellcheck disable directive (which also clears
actionlint's last SC2086 warning). Rationale lives in git history.