ci: publish npm packages to CodeArtifact alongside Nexus

[crisp2u]

What

Appends a best-effort CodeArtifact publish leg to the publish job, right after the existing Nexus publish:

1. Configure AWS (CodeArtifact) — assumes this repo's publish OIDC role (vars.ENVIRONMENT_PUBLISH_AWS_OIDC_IAM_ROLE_ARN).
2. Authenticate to CodeArtifact — mints a short-lived token (masked before it reaches $GITHUB_OUTPUT) and resolves the npm-empg endpoint.
3. Publish to CodeArtifact — npm publish --registry <CodeArtifact endpoint> from the repo root, mirroring the Nexus publish.
4. Report CodeArtifact result — writes the outcome to the run summary.

It also adds the job-scoped permissions: block OIDC needs (id-token: write), which as a side effect narrows the default GITHUB_TOKEN down to contents: read.

Why

Part of the Nexus → CodeArtifact migration (DEVOPS-1222). Publishing to both registries lets consumers move across one at a time; Nexus stays authoritative until they have.

Safety

• Every CodeArtifact step is continue-on-error: true and gated on the previous step's outcome, so a CodeArtifact problem can neither fail a release nor run a half-configured step.
• The Nexus publish is untouched. The CodeArtifact auth line is keyed on the CodeArtifact endpoint's own host and path, so it cannot disturb the Nexus one.
• npm publish --registry overrides publishConfig.registry on npm ≥ 10.8.2 — .nvmrc pins node 20.19.0 ⇒ npm 10.8.2 — so no package.json is mutated.
• zizmor: the new permissions: block clears the excessive-permissions finding this workflow had before; the only new finding is unpinned-uses on the tag-pinned SectorLabs/actions/configure-aws, which is the same form used everywhere else in the org and by the repos already migrated.

Validating

The IAM role trusts v* tag refs only, so this leg cannot be exercised from a PR run — the first real check is the next release tag. Read the Report CodeArtifact result line in that run's summary rather than the step ticks: continue-on-error reports a failed step as green.