fix(registry): retry transient registry-server faults

[moshest]

Last night's nightly publish (run #165):

Succeeded: 48   Skipped: 9   Failed: 1
  npm/preact@latest: fetch failed

One dropped connection out of ~58 packages exits the run non-zero and leaves the registry a day stale. This is the second distinct cause of a red nightly this week — the first was a broken package definition (fixed in #105), and it was worth waiting to see what the next failure looked like before deciding how to harden the job.

The gap

version-check.ts already retries public-registry calls with exponential backoff via p-retry. The two fetches to our own registry server, in publish.ts, had no retry at all — so a transient fault on either the existence check or the upload killed the package, and with it the run.

Both now go through the same pattern: 5xx and network faults retry, 4xx aborts immediately because that is the server's considered answer rather than a blip. No new dependency; p-retry is already used a file away.

Publishing is safe to retry — the server keys on registry/name/version, so a retry after a dropped connection overwrites rather than duplicating.

Why not just stop failing the run

I considered making publish-all exit zero when some packages succeed, and rejected it. The pipeline reported the lucia breakage correctly for five straight nights; nobody was watching. Exiting zero would mean a genuinely broken definition is never noticed at all — trading a loud, fixable failure for silent rot. Retrying the transient class while still failing loudly on the permanent class targets the actual problem.

Verification

Against a local server that drops the first two connections and then answers:

checkPackageExists: survived 2 dropped connections -> null
publishPackage:     survived 2 dropped connections -> resolved
403 aborts after 1 attempt: "Failed to publish npm/x@1: 403 Forbidden — forbidden"

Both new tests are mutation-verified: setting retries: 0 fails only the retry test; removing the AbortError branch fails only the 4xx test (it hangs through the full backoff, then throws the wrong shape).

Error messages also now carry the server's response body on both paths — the existence check previously discarded it, which is what turned this outage into the bare string "fetch failed".

pnpm lint    ✓
pnpm build   ✓
pnpm test    ✓  221 + 41 passed

No changeset — @neuledge/registry is private: true.

---

Generated by Claude Code

[changeset-bot]

⚠️ No Changeset found

Latest commit: 6db4986

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR