fix(release): stop failing a release whose packages did reach the registry

[ardelperal]

Closes #307

What happened

The v1.17.0 Release run (34693660213) went red on "Verify every package is actually on the registry":

@aroman22/codegraph-vba-win32-x64@1.17.0 never appeared on the registry

The release had shipped correctly. Verified end to end, not inferred:

$ npm install @aroman22/codegraph-vba@1.17.0
added 2 packages in 5s          # shim + codegraph-vba-win32-x64
$ node_modules/.bin/codegraph-vba --version
1.17.0

All six per-platform packages plus the shim are on npm at 1.17.0, signed, with valid integrity hashes, and the shim's optionalDependencies point at 1.17.0 for all six.

A gate that cries wolf is worse than no gate — the next real publish failure gets waved off as "that flaky step again". So this fixes the step rather than the symptom, and keeps it fatal.

Root cause

1. The budget was too short for how big these packages are.

package	unpackedSize
linux-x64	235,734,927
darwin-x64	235,191,186
linux-arm64	233,630,093
darwin-arm64	232,869,672
win32-x64	204,574,713
win32-arm64	193,321,471

Each bundles a Node runtime — ~200 MB over ~1,000 files. npm's own registry metadata timestamps codegraph-vba-win32-x64@1.17.0 at 12:33:15.765Z, while the publish step had already finished before the verify step began at 12:30:06: the registry took over three minutes to make that one resolvable. The budget was 20 × 10 s = 200 s.

2. The loop slept after its last failed check and exited without looking again.

for i in 1 2 3 … 20; do
  if npm view "$name@$V" version >/dev/null 2>&1; then ok=1; break; fi
  echo "waiting …"; sleep 10        # ← 20th sleep, never re-checked
done
[ -n "$ok" ] || { echo "::error::…"; exit 1; }

The final check ran at 12:33:23 — 8 s after the package landed, still missing it through the CDN — then the run slept 10 s and errored without a further look. The last wait was thrown away.

The change

• Final check after the loop, closing the off-by-one.
• 60 attempts instead of 20 (~10 min), with the attempt count and interval lifted into env: so they are visible, and the reason recorded in a comment: a future reader who trims it back will first read why it is long. Only whichever package was published last tends to lag, so the worst case is one package's wait, not six.
• Progress lines now read ($i/$VERIFY_ATTEMPTS) instead of a bare counter.

Nothing else in the workflow changes, and a package that genuinely never arrives still fails the release with the same error.

Verification

The step is shell inside a workflow, so it was exercised directly against a stub npm that starts succeeding at a configurable attempt — the three cases that matter, with VERIFY_ATTEMPTS=3:

scenario	before	after
appears only on the post-loop check (the #307 case)	fail	verified, exit 0
appears mid-loop	pass	verified, exit 0 (short-circuits, no further sleeps)
genuinely absent	fail	ERROR never appeared, exit 1

The workflow YAML was also parsed to confirm the new env: block is well-formed (VERIFY_ATTEMPTS: 60, VERIFY_INTERVAL_SECONDS: 10).

Not in scope

The v1.17.0 release itself needs no action — it is published, installable and correct. This only stops the next one from being reported red for the same non-reason.