fix: retry npm view with backoff in verifyPublishedArtifact

[lacymorrow]

Summary

• Fix false-positive "Could not verify" warning after every successful publish.
• Retry npm view <pkg>@<ver> up to 5 times with backoff (0s, 2s, 5s, 10s, 20s — ~37s max) before warning.

Context

The verify step added in #49 worked correctly, but npm view was being called immediately after npm publish returned — before the npm registry CDN had propagated the new version. Result: every release saw "Could not verify @ on the registry" even though the publish succeeded.

Concrete trigger: lacy@1.8.19 released cleanly today, but the user got the warning, then npm view lacy@1.8.19 returned the correct artifact a few seconds later. Same race that produces the post-publish ETARGET issue with npx ("No matching version found") — npm registry edge nodes lag.

Behavior

• First attempt is still immediate (zero delay), so packages that have already propagated by the time we get here see no slowdown.
• Subsequent retries spaced 2s, 5s, 10s, 20s — total ~37s before giving up.
• The warning text changed slightly: "...after retries" instead of "...(npm view failed)".

Test plan

• bun run typecheck clean
• bun run test — 60 pass, 0 fail
• Manual: release a real package and confirm no spurious warning

[gemini-code-assist]

Code Review

This pull request introduces a retry mechanism with backoff delays when executing npm view to verify published artifacts, helping to mitigate issues caused by registry propagation lag. However, the synchronous sleep helper sleepSync uses Atomics.wait on a SharedArrayBuffer, which is not allowed on the main thread in Node.js or Bun and will throw a runtime TypeError. It is recommended to implement a safe synchronous sleep by spawning a short-lived child process instead.

[gemini-code-assist]

Using Atomics.wait on the main thread in Node.js or Bun throws a TypeError: Atomics.wait cannot be called on the main thread at runtime, which will crash the CLI tool during the verification step.

Since verifyPublishedArtifact is synchronous and we cannot modify its callers (as they are outside the diff hunks), we can implement a safe synchronous sleep by spawning a short-lived child process using the already-imported exec helper. This blocks the main thread synchronously without pegging the CPU (unlike a busy-wait loop) and avoids the Atomics.wait restriction.

function sleepSync(ms: number): void {
	if (ms <= 0) return;
	try {
		exec(process.execPath, ["-e", `setTimeout(() => {}, ${ms})`]);
	} catch {
		// Ignore
	}
}

[lacymorrow]

Respectfully pushing back — verified locally that Atomics.wait on the main thread works in both Node and Bun:

$ node -e "const buf=new Int32Array(new SharedArrayBuffer(4));const t=Date.now();Atomics.wait(buf,0,0,200);console.log('elapsed:',Date.now()-t)"
elapsed: 205

$ bun -e "const buf=new Int32Array(new SharedArrayBuffer(4));const t=Date.now();Atomics.wait(buf,0,0,200);console.log('elapsed:',Date.now()-t)"
elapsed: 205

The "cannot be called on the main thread" restriction is a Web Platform rule (browsers prohibit it to keep the UI thread responsive). Node.js explicitly permits it on the main thread — that's documented behavior, not an accident.

Bun matches Node here (it ships V8 Atomics; same semantics).

The proposed spawn(process.execPath, ["-e", ...]) workaround would fork a full Node process per sleep — ~50-100ms of overhead before the actual sleep starts, plus extra CPU/memory. The Atomics.wait approach is the standard idiomatic sync-sleep in Node and is correct here.

Keeping the current implementation.