release: retry the attestation download, and say why when it fails

[justinjoy]

Refs #1290. Stacked on #1289, which owns release-tag.yml.

The defect

The workflow attested the archive and downloaded the bundle in the next step, back to back, with no delay and no retry:

(cd dist && gh attestation download "wirelog-"*.tar.gz --repo "$GITHUB_REPOSITORY" --limit 1)
attestation=$(find dist -maxdepth 1 -type f -name 'sha256*.jsonl' -print -quit)
test -n "$attestation"

Those are separate API operations. Without read-your-writes consistency the download returns nothing and the job dies on a bare test -n — after every verification job has passed, on a tag that cannot be rebuilt.

Extracted, not just patched

The retry lives in scripts/release/download-attestation.sh so it can be exercised without cutting a release. That is the point rather than a side benefit: this is code whose first real execution is a release. Same reasoning #1293 established for generate-sbom.sh.

The failure path now diagnoses:

no attestation bundle for wirelog-9.9.9.tar.gz after 5 attempts
  The attest step and this download are separate API operations, so the
  usual cause is replication lag rather than a missing attestation.
  Check https://github.com/<repo>/attestations before re-running; if the
  attestation is listed there, re-running this job alone is enough.
  gh said: ...

Two problems the retry itself created

Both found in review, both regressions against the inline original:

problem	why it exists
a stale bundle from an earlier run satisfied the existence check on attempt 1, and would be renamed and published as this release's provenance	swallowing gh's status (needed so a transient failure doesn't abort before the loop runs) means success is decided by "a bundle exists", not "this download produced one". The inline form couldn't do this — gh's exit aborted the step
a zero/non-numeric attempt count ran the loop zero times, never called gh, and still printed the full replication-lag diagnosis	a confidently wrong answer

Both guarded and pinned. Currently unreachable in CI (fresh VM per job), but the guard is now the code rather than runner ephemerality.

Also fixed in review: an assertion that gave false credit for the diagnosis text — the needle attestations was satisfied by the stub's own stderr (no attestations found for subject), so deleting the URL and re-run guidance left the suite green. It now matches text only the script can produce.

Validation

• 23 assertions, suite abi. Confirmed by the reviewer to actually run in release-tag.yml's ABI job and ci-pr.yml — needs only bash and a stubbed gh, no b3sum. (I have shipped two tests this session that skipped in 100% of CI; this one was checked.)
• Mutations killed: removing the retry (the original bug), removing the stale-bundle guard, removing the attempts validation, removing the URL guidance, cp instead of mv, dropping the gh quote, leaving the log behind
• The test asserts it actually retried, by counting stub invocations, rather than inferring it from success
• No pipelines in the new script, so the pipefail early-exit class this repo has hit seven times is structurally absent
• Full suite 306 Ok / 0 Fail / 12 Skipped

One redirection-order bug of mine was caught by the suite itself: 2>/dev/null >&2 sends stdout to /dev/null, swallowing the gh output that line exists to print.