fix(release): link the three binaries one at a time in binaries.yml

[vyncint]

Today

Every Linux binary job of the last two releases died at the same point: linking oxidelake-runtime after all 444 dependencies had compiled, with The runner has received a shutdown signal, exit 143.

Release	Job	Died after	Last crate in flight
v0.1.0	aarch64-unknown-linux-musl	9m16s	oxidelake-runtime
v0.1.0	x86_64-unknown-linux-musl	13m46s	oxidelake-runtime
v0.1.2	aarch64-unknown-linux-musl	8m55s	oxidelake-runtime

v0.1.0 shipped with macOS archives only; its macOS jobs took 4h11m and 4h37m.

Why

The release profile is lto = "fat", codegen-units = 1. Each binary's link is a whole-program LLVM pass over Arrow, DataFusion and Ballista, and Cargo schedules the three binaries' links in parallel. Three of those exceed a 16 GB Linux runner with no swap, so the VM is torn down. macOS swaps instead, slowly. cargo install from crates.io passes because a crate built outside the workspace does not carry the workspace release profile.

Change

• Build with one cargo build --release --locked -p oxidelake-runtime --bin <name> --target <t> per binary. Dependencies compile in parallel during the first call; the other two only link, so one LTO pass is in memory at a time.
• A re-run against an existing tag checks the release first and skips targets whose archive is already attached. docs/RELEASING.md already documents gh workflow run binaries.yml --ref main -f tag=vX.Y.Z for this; it now costs nothing for targets that are done.
• CHANGELOG under [Unreleased].

Verified

• make zizmor (pedantic): no findings. YAML parses.
• The skip step dry-run locally with the real gh against v0.1.2/aarch64 musl (absent → build), v0.1.0/aarch64 darwin (present → skip), and a nonexistent tag (build).

Not done

• No automated test covers the workflow shell. The link change is verified by dispatching binaries.yml at main for v0.1.2 after this merges; the Linux archives are the evidence.
• The release profile itself is unchanged, per the audit's note not to alter production optimisation for CI's sake. The macOS runners will still swap through a single LTO link, just one at a time.