fix(tests): resolve SC2015 in mktemp guards

[adbarc92]

Fixes the ShellCheck job, red on main since 2026-07-25. It was the only failing job — all four test jobs pass.

The finding

Four files carried the same guard, validating mktemp output before installing a rm -rf trap:

[ -n "$WORK" ] && [ -d "$WORK" ] || { echo "FATAL: bad WORK" >&2; exit 1; }

ShellCheck raises SC2015 (A && B || C is not if-then-else). Here it is arguably a false positive — both operands are tests, so C running when B fails is the intent. I did not suppress it: the guard protects a rm -rf, and it should say what it means.

if [ -z "$WORK" ] || [ ! -d "$WORK" ]; then echo "FATAL: bad WORK" >&2; exit 1; fi

Identical semantics, no shellcheck disable anywhere. Files: tests/simple-test.sh, tests/mutate.sh, tests/spec-map.sh, tests/oracle-gate.sh.

Evidence nothing was weakened

• bash tests/simple-test.sh → 202 passed, 0 failed — identical to before
• oracle.lock.json's tests[] array is byte-identical, 202 entries
• bash -n clean on all four
• Guard behavior re-verified: fires on empty, fires on a missing directory, silent on a good one

⚠️ The freeze gate will fail R7, and that is correct

Three of these files are content-hashed by the oracle. The gate now reports:

GATE FAIL [R7] NEEDS_HUMAN: tests/simple-test.sh changed
GATE FAIL [R7] NEEDS_HUMAN: tests/oracle-gate.sh changed
GATE FAIL [R7] NEEDS_HUMAN: tests/spec-map.sh changed

oracle-gate.sh states that --accept is "a deliberate human act", so this PR does not re-lock itself. An agent that edits the tests and then re-arms the gate over its own change is the exact tamper path this repo is built to stop.

To land: review the diff above, then:

bash tests/oracle-gate.sh --accept
git commit -am "chore(tests): re-lock oracle after SC2015 guard fix"

CI goes green after that.