fix(ci): continue release after registry miss

[vincentkoc]

What Problem This Solves

Fixes an issue where the protected release workflow exited before npm publish
when the requested package version was correctly absent from the registry.

The first v0.4.6 run validated the tag, changelog, package, tests, and tarball,
then failed in the publish/recovery step:
https://github.com/openclaw/fs-safe/actions/runs/30086619672

Why This Change Was Made

Keep errexit control at the two existing call sites. The registry verification
helper no longer re-enables it internally before returning the expected E404
status, so the workflow can proceed into npm trusted publishing.

User Impact

This unblocks publication of @openclaw/fs-safe@0.4.6. Runtime package behavior
is unchanged by this repair.

Evidence

• Executed the exact embedded publish block with a fake registry:
  E404 before publish, matching integrity and provenance after publish; exit 0.

• git diff --check

• Autoreview: clean, no accepted or actionable findings.

• The failed release run completed all validation and package checks before the
  affected publish/recovery step.

• Tests added or updated when behavior changed

• Security and compatibility impact considered

• CHANGELOG.md updated when release-relevant

• No credentials, private paths, private hosts, or sensitive contents included

[clawsweeper]

ClawSweeper status: review started.

I am starting a fresh review of this pull request: fix(ci): continue release after registry miss This is item 1/1 in the current shard. Shard 0/1.

This placeholder means the worker is alive and reading the current context. I will edit this same comment with the actual review when the claws are done clicking.

Crustacean status: shell secured, claws on keyboard, evidence pebbles being sorted.

[vincentkoc]

Release recovery decision:

• @openclaw/fs-safe@0.4.6 is absent from npm.
• GitHub release v0.4.6 does not exist.
• The existing tag triggered validation but exited before npm publish.

After this repair merges, delete and recreate the protected signed v0.4.6 tag
on the repair merge commit, then let the tag-driven workflow publish and verify
the exact artifact. No package version has been published under the old tag.