fix(ci): gate release on npm registry propagation

[svozza]

Summary

publish_layer's cdk synth runs npm i @aws-lambda-powertools/<pkg>@<version> seconds after npm publish returns, before registry.npmjs.org actually serves the new versions. needs: publish-npm only guarantees publish returned, not that the registry resolves the versions, so the layer build intermittently fails with a misleading ETARGET / No matching version found (as in the v2.35.0 release), which blocks every downstream job. This adds a registry-availability gate plus a retry so the release either waits or fails with an accurate reason.

If the gate does time out because of registry eventual consistency, it is safe to simply re-run the failed job once npm catches up — nothing needs to be republished.

Changes

• Add .github/scripts/verify_npm_publish.sh: after publishing, poll the registry for every non-private workspace version (version document + dist.tarball) until it is served, failing after 7 minutes with a message that names the pending versions and explains the ETARGET symptom, rather than letting it surface later.
• Wire a Verify npm registry propagation step into the publish-npm job, so publish_layer and create_tag (both needs: publish-npm) transitively wait.
• Retry the layer bundling npm i with exponential backoff in layers/src/layer-publisher-stack.ts, which also protects the manual publish_layer dispatch path.

Testing

Rehearsed end-to-end against a full stubbed copy of the release pipeline (npm publish, AWS, and CDK deploy edges stubbed; job graph, gating, and artifact flow kept real):

• Happy path: with the versions live on the registry, the Verify npm registry propagation step passes against the real registry and the layer build's cdk synth/npm i succeeds; the pipeline proceeds.
• Negative path: with a version unavailable, the gate fails loudly — naming the pending version and the ETARGET symptom rather than surfacing a bare ETARGET downstream — and publish_layer/create_tag are skipped.

Issue number: closes #5564

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.