codec-native-build's 4 GiB cap is within 6% of the release compile's peak #781

Problem

codec-native-build (in scripts/conformance/server-parity/codec-operations-build.sh) compiles the release server in a container capped at 4 GiB with no swap: --cpus=1 --memory=4g --memory-swap=4g, CARGO_BUILD_JOBS=1. The script's comment says the compile "peaks near 2 GiB". It now peaks much closer to the cap.

On PR #776's exact head, run 40321678938 attempt 1 lost this job: the final durable-workflow-server rustc was killed by signal 9 with no compiler diagnostic. The single rerun passed. Security accepted the classification as a resource kill and asked for the CI memory bound itself to be treated as the defect if it recurs near the cap.

Measurement

Local release builds with CI's settings (--release --locked, jobs 1, incremental off, release debug 0) in a container capped at exactly 4 GiB, no swap, on the same compiler image. The peak is the container cgroup's memory.peak, which includes page cache.

The same #776 build with an 8 GiB cap peaked at 4,746,670,080 B, because page cache grows when nothing reclaims it.

So both trees fit, but within about 6%. One feature PR added about 66 MB, and the compile will keep growing. A hosted runner under memory pressure can tip it over, as attempt 1 shows.

Proposed fix

Raise the container cap to 6 GiB (--memory=6g --memory-swap=6g) and record the new bound in build.json. GitHub's standard hosted Linux runners have 16 GB, and this job runs only this one build container, so the runner has room.

Update the script's comment to the measured peak, and keep CARGO_BUILD_JOBS=1 so the bound still means one rustc at a time.

The job's purpose, a bounded optimized artifact for deadline health, is unchanged; only the bound's headroom changes.

This is a CI-only change, with no product source.

🤖 Generated with Claude Code