fix(guard): apr_bin.sh refused a HEAD-built binary sitting next to a stale one

[noahgift]

Is apr_bin.sh superior or inferior to the rest of the stack?

Superior — it is the only one. Surveyed all seven sibling repos:

repo	binary resolver	SHA-vs-HEAD freshness
pmat, realizar, batuta, copia, forjar	none	0 scripts
trueno, bashrs	none	1 script each
aprender apr_bin.sh	yes	yes, fail-closed under APR_BIN_STRICT

Skills: repo-scope apr-dogfood sources it correctly (. scripts/apr_bin.sh \|\| exit 1 + APR_BIN_STRICT=1). User-scope dogfood has no binary resolution at all — which is the shadowing hazard already recorded, since a user-scope skill can shadow a repo one by name.

It is also well-hardened already: refuses to search PATH, derives the target dir from cargo metadata rather than a hardcoded path, uses git rev-parse --show-toplevel instead of the bash-only BASH_SOURCE (which broke under zsh), and fails closed outside a checkout in strict mode.

The defect

apr_bin_resolve returned target/release/apr whenever it existed, then handed it to the freshness check — which refused it. Measured on a real checkout, debug/apr built from HEAD beside a stale release/apr:

STALE apr BINARY
  resolved : .../target/release/apr
  reports  : apr 0.60.0 (v0.60.0+no-git)
  HEAD     : 75d6610d8

It hard-fails and tells you to cargo install while a provably correct binary sits in the next directory. Every gate sourcing this file breaks that way, and the trigger is only "you ran cargo build --release here once".

The fix

The candidate set is unchanged, so the never-search-PATH property still holds. Only the order within it is now evidence-driven: first candidate whose embedded SHA matches HEAD wins. Fixed order remains the fallback, so an all-stale checkout still resolves something and reports STALE rather than "no apr binary found" — a worse diagnosis for the same situation.

The stale report now lists every candidate with its version, not only PATH shadows. Today's failure was a fresher binary in a sibling directory, which the old message had no way to show.

Falsifier

check_apr_bin_resolution.sh — four rows on throwaway git checkouts with fabricated binaries (shell scripts printing a version string; the resolver only substring-matches the sha, so no cargo build is needed):

stale release + fresh debug -> resolves DEBUG      <- the regression
fresh release + stale debug -> resolves RELEASE    <- order still honoured
both stale                  -> REFUSES
no binaries at all          -> REFUSES

Mutation: remove the freshness preference → row 1 goes RED, rows 2–4 stay green. Precisely the regression and nothing else.

check_apr_bin_pinned.sh cannot catch this class — it asserts that callers pin the binary, never that the resolver hands them the right one. Nothing exercised resolution order until now.

Wired into guard-runner-labels, which is in gate.needs, so it blocks rather than informs.

bashrs

0 errors. Two findings were the known false-positive classes, worked around at the source rather than suppressed: the fixture Cargo.toml is printf'd instead of heredoc'd (bashrs parses an embedded heredoc as shell, so TOML name = "x" reads as SC1007), and the version string's parens are kept off any line holding a [ ] test (SC1028).

The third — SEC011 on an unvalidated rm -rf "$dir" — was right, and now uses this repo's "${dir:?}" idiom.