fix(build): put the whole GOT inside the RELRO window on ELF targets

[DeusData]

Distilled from #1138 with Co-authored-by: credit to @PR9000. Takes the two flags worth taking, leaves the rest, and asserts the result on the artifact rather than on the compiler accepting a flag.

Every Linux binary we have shipped had part of the GOT left writable

Measured on a binary built the way .github/workflows/_build.yml builds the Linux release (STATIC=1, gcc 13.3 / GNU ld 2.42, Ubuntu 24.04 aarch64). PT_GNU_RELRO ends at 0x11DA0000 in both cases:

without -z now:  .got     0x11d9ec20 +0x13c8
                 .got.plt 0x11d9ffe8 +0x40   -> ends 0x11DA0028
                 ...40 bytes PAST the RELRO window: those GOT slots stayed
                 writable for the entire process lifetime.

with    -z now:  .got.plt folds into .got, ends 0x11D9FFE8
                 ...the whole GOT is inside the window and re-mapped read-only.

Both flags are free at runtime here — a static binary resolves everything at link time, so there is no lazy binding left to pay for. -z relro is already this toolchain's default and changes nothing on it; it is named anyway so the property stops depending on one distro's spec file, since the musl/portable and glibc-floor images are different toolchains and a default is not a guarantee.

The assertions are the point

A1c-relro and A1d-bind-now in check-binary-composition.sh read the produced binary with readelf and assert the outcome — the same reason A1 exists beside the .note.GNU-stack annotation.

#1138 is the direct evidence for why that matters. Two of its flags passed every compile probe and did nothing, or worse:

• -pie was silently discarded under -static. Probe passed, flag added, artifact unchanged (Type: EXEC, no PIE).
• -D_FORTIFY_SOURCE=2 silently DOWNGRADED Ubuntu 24.04's default of 3, with no diagnostic, on the exact platform that builds the shipped Linux binaries. A hardening flag that weakened hardening.

A probe answers "does this flag compile", never "did the binary gain anything".

The readers use awk rather than a short-circuiting reader deliberately: a reader that exits at the first match leaves the upstream taking EPIPE, and under set -o pipefail the satisfied case gets reported as the failing one. That is the same defect fixed in #1879 earlier today, avoided here by construction.

Deliberately not taken from #1138

flag	why not
-D_FORTIFY_SOURCE=2	measured downgrade from Ubuntu's 3. If fortification is touched at all it may only be raised, never lowered
-fPIE / -pie	inert under STATIC=1, which is how Linux release binaries are built. Adding it would be false assurance
-fstack-protector-strong	real but unmeasured cost, and #1138 injected it into SQLite, tree-sitter, mimalloc, lz4 and zstd — the indexing hot loop, on a project that indexes 8.5M-node graphs. Wants a same-machine A/B index run first
the $(shell) probe machinery	~10 compiler spawns per Makefile parse (measured 209 ms, paid on every make including clean and -n), and it makes the produced binary a function of whichever toolchain the builder happens to have
everything else	already merged via #1421 / #1423 / #1467, or superseded — main's TSan define fix and its FreeBSD-guarded /home alias are both better than the versions in that PR

No new opt-in knob: main already applies ELF_HARDENING_FLAGS unconditionally on ELF and ships that way, so two more free linker flags join the existing set rather than growing a PRODUCTION_HARDENING-style variable.

Honest limit: macOS cannot show ELF program headers, so the RELRO/BIND_NOW outcome is verified by the measurement above and by the new assertions running in CI's Linux legs — not on this machine.

[DeusData]

test-diag diagnosed. It is not environmental — correcting an earlier read of mine that stopped at the first error line in the log.

The log opens with ERROR: repository build/ ancestor must be absent or a real directory, which is the same signature two unrelated PRs hit and which was environmental for them. That line is noise here. The job actually dies further down, at Step 0o, the MCPB bundle contract (#1246), on this PR's own new assertion:

--- packaging the four target families from one stub build tree
BINARY COMPOSITION GATE FAILED: 1 assertion(s) over 1 binary/binaries
  - A1d-bind-now stage/codebase-memory-mcp: GOT section(s) .got.plt fall outside
    PT_GNU_RELRO [15824,16384) — they stay WRITABLE after relocation (link with -z now)

A1d-bind-now is the assertion this PR adds. Step 0o builds stub binaries — "four target families from one stub build tree" — and a stub is not linked with -z now, so the assertion is correct about the binary in front of it and wrong about which binaries it should be inspecting.

So the gate as written applies a release-binary property to a packaging fixture. Two ways out:

1. Scope the assertion to real release artifacts and skip stubs — matches the intent, since the property being protected is about what ships.
2. Link the stub tree with -z now too, so fixtures satisfy the same contract as the artifacts they stand in for. Stronger, and it keeps the gate from silently developing exemptions, but it means the stub build has to track link flags it otherwise does not care about.

(1) is the smaller change; (2) is the one that will not quietly rot. Worth deciding deliberately rather than reaching for whichever makes the leg green.

Reproduced on the second run, so this is deterministic, not flake: run 33262210460, attempts 1 and 2, identical assertion both times.