fix(_publish-npm): make the corepack npm upgrade actually take effect

`corepack prepare npm@latest --activate` only records the version in
COREPACK_HOME. It does not put that npm on PATH, so `npm` keeps
resolving to the runner's bundled copy and the upgrade silently
no-ops - the step still prints a reassuring "Updated npm version" line
and exits 0.

Observed on Zondax/ledger-filecoin-js v3.0.10, the first release to run
this workflow at @v11:

    Current npm version: 10.9.8
    Updated npm version: 10.9.8
    ...
    NODE_AUTH_TOKEN: XXXXX-XXXXX-XXXXX-XXXXX
    npm http fetch PUT 404 https://registry.npmjs.org/@zondax%2fledger-filecoin
    npm error 404 '@zondax/ledger-filecoin@3.0.10' is not in this registry.

npm 10.9.8 predates OIDC trusted publishing, so rather than exchanging
the OIDC token it authenticated with the placeholder _authToken that
setup-node writes into .npmrc, and the registry reported the
unauthorized publish as a misleading E404. Provenance still signed
correctly in that run, which is why the failure looks like a
trusted-publisher misconfiguration rather than a stale npm.

Reproduced locally, independent of CI:

    baseline npm                          11.5.2
    after `corepack prepare --activate`   11.5.2   <- no-op
    after `corepack enable npm` + prepare 12.0.2

Two changes:

- run `corepack enable npm` before `corepack prepare`, so the shim that
  routes `npm` through corepack is actually installed
- assert npm >= 11.5.1 afterwards and fail the job if not

The assertion matters as much as the fix. The v11 regression shipped
because dry-run mode skips the publish step entirely, so every consumer
PR went green while the real release path was broken. The guard runs on
dry-run too, which turns this class of failure into a red PR instead of
a failed release.

Author: chcmedeiros

.github/workflows/_publish-npm.yaml

@@ -123,11 +123,29 @@ jobs:
         # (`Cannot find module 'promise-retry'`). Corepack installs npm as a
         # tarball and atomically swaps the active version, sidestepping the
         # in-place mutation that breaks the self-upgrade path.
+        #
+        # `corepack prepare --activate` on its own only records the version in
+        # COREPACK_HOME - it does NOT put that npm on PATH, so `npm` keeps
+        # resolving to the runner's bundled copy and the upgrade silently
+        # no-ops. `corepack enable npm` installs the shim that actually routes
+        # `npm` through corepack, so it has to come first.
         run: |
           echo "Current npm version: $(npm --version)"
+          corepack enable npm
           corepack prepare npm@latest --activate
           echo "Updated npm version: $(npm --version)"
 
+          # Fail loudly if the upgrade did not take. Without this, an old npm
+          # falls through to the placeholder _authToken that setup-node writes
+          # into .npmrc, and the registry reports an unauthorized publish as a
+          # misleading `E404 ... is not in this registry`.
+          NPM_VERSION="$(npm --version)"
+          REQUIRED_NPM="11.5.1"
+          if [ "$(printf '%s\n%s\n' "$REQUIRED_NPM" "$NPM_VERSION" | sort -V | head -n1)" != "$REQUIRED_NPM" ]; then
+            echo "::error::npm $NPM_VERSION is too old for OIDC trusted publishing (need >= $REQUIRED_NPM). The corepack upgrade above did not take effect."
+            exit 1
+          fi
+
       - name: Build package
         run: if grep -q '"build"' package.json; then ${{ steps.pm.outputs.pm }} build; else echo "No build script found, skipping"; fi