fix(ci): retry the npm audit, so an unreachable registry is not read as a finding

[wshallwshall]

Why

npm audit exits non-zero both when the advisory database reports a vulnerability and when it cannot be reached. The bare npm audit --package-lock-only this replaces made the two indistinguishable, so a red on the required npm-audit (ide dependency vulnerabilities) context said nothing about the dependencies. That is a compensating control resting on a false premise.

Measured 2026-09-04. Of 34 failures of that required context in one night, 32 were transport errors (503 Service Unavailable, or network timeout at https://registry.npmjs.org/-/npm/v1/security/advisories/bulk) and 2 were real findings on other jobs. Each false one blocked a merge or evicted a merge-queue entry; one pull request was evicted from the queue seven times on this alone, and three more were pushed to UNMERGEABLE by it while this was being written.

What changed

The step retries five times with backoff, and decides "verdict or transport failure" on the content of the audit output (.metadata.vulnerabilities) rather than on exit status, which cannot separate them.

This is a strengthening, not a relaxation

The gate stays fail-closed, and that is the property the test pins:

• the only exit 0 sits inside the branch where npm audit itself succeeded;
• exhausting the retries exits 1, with a message saying no verdict was obtained;
• nothing added here can turn a real advisory green.

The one assumption I cannot verify without a networked runner is that npm audit --json emits .metadata.vulnerabilities on a verdict and omits it on a transport error. It is arranged so that being wrong about it is safe: if the discriminator never matches, a real finding is treated as "no verdict", the retries exhaust, and the job fails. The assumption can cost a false red; it cannot produce a false green.

Verification

tests/test_npm_audit_retry.py grades the fail-closed property, not a signature. Three arms, disjoint reds:

arm	change	result
A	unmutated	5 pass
B	fail-open exit 0 added after the retry loop	2 tests fail (the exit 0 count, and the tail check)
C	exactly one exit 0, but guarded by if [ -f package-lock.json ] instead	only the enclosing-block check fails

Arm C matters: it keeps the count unchanged, so it confirms the enclosing-if walk works independently rather than riding on the count assertion.

An earlier version of that test searched the whole preface for if npm audit, which every later line trivially satisfies. It passed arm B and so proved nothing. It was rewritten to walk backwards to the genuinely enclosing block, tracking fi.

Also adds the tests/tooling_manifest.txt line the partition test requires.

Checks run locally

ruff format --check, ruff check, tests/test_npm_audit_retry.py, tests/test_tooling_partition.py — all green. The workflow's own effect is only observable on a hosted runner, so the Security leg here should be read before merging.