backlog: file item 1312 -- the release-age guardrail test passes off the live network

[wshallwshall]

Found while triaging PR #487. Three rows of
test_release_age_passes_an_aged_release_and_holds_a_fresh_one now RUN on
windows-2025 (rc=0, so the step body completed) and FAIL, every one returning
age_ok='true' where 'false' is expected.

THE PASSING ROW IS THE FINDING. The test's own comment calls aged 30 days the
discriminating pass, "without this row the whole release-age suite would be
satisfied by a step that denies unconditionally." It is green because
requests==2.32.3 really is old -- a fact about PyPI, not about the guardrail.

The reading is forced by the workflow being fail-closed rather than inferred from
the failures. Every branch of the age step routes to age_ok=false: unwired
ecosystem, empty or ERR pairs, blank newVersion, name or version failing shape
validation, ERR or empty body, missing or null timestamp, unparseable date,
future date, under-age. true reaches the output only from a real aged upload
time, so true on a row whose fixture is {"urls":[]} is positive evidence the body
reached the network. The workflow is NOT the defect.

Not the cwd/script.name change: I replicated both invocation forms against Git
Bash with full_env built the same way and the same chmod(0o755) stub, and the
stub interposed under BOTH. The open question is which interpreter require_shell
resolves on that runner image, which cannot be measured off the runner.

The test discards the one output that would settle it. _run_step_body captures
the child and returns only what it parses out of GITHUB_OUTPUT, so the step's own
"was published Nh ago" notice and every ::warning:: never reach the CI log. The
failure reports a wrong boolean and withholds the sentence naming the age it
computed. That is step one of any fix, before theorising about PATH.

Downstream of #1216/#1272, not an objection to them: require_shell is what made
these rows run at all, and this was invisible underneath the WSL-launcher
failures it removed. Nobody holds either number -- the Builder 1 seat measured
zero claim rows and zero commits for both, with a positive control, and declined
the hand-off -- so this needs a dispatcher assignment rather than an owner by
default.