fix(publish-npm): use corepack to upgrade npm instead of npm self-install

[0xPxt]

Value

• Unblocks every consumer of _publish-npm.yaml — the previous npm install -g npm@latest step has been failing on GitHub-hosted runners with Cannot find module 'promise-retry' for the past ~2 months, breaking all dry-run publish checks and silently masking real publish-time errors.
• One-line behaviour change, same npm version semantics (@latest still resolves to latest), no input contract changes — drop-in compatible with every consumer pinned at v5/v6/v7/v8/v9.

Why this broke now (the workflow line didn't change)

• npm install -g npm@latest asks npm to upgrade itself in-place. While the upgrade is running, the old npm's node_modules (including promise-retry) gets unlinked mid-install — and the running process then tries to require('promise-retry') from those same paths.
• This used to work because the running npm and the target npm both shipped the same arborist family (v7). Around early-to-mid 2025, npm@latest rolled to npm 11.x, which uses arborist v8 with a reorganised internal layout. The running arborist v7 doesn't tolerate the new layout's deletion order — promise-retry is gone by the time arborist needs it during rebuild.
• The workflow file hasn't changed; what @latest resolves to has. Same trigger that would hit any other consumer the moment their checks job starts passing.

Technical

• .github/workflows/_publish-npm.yaml — replaces npm install -g npm@latest with corepack prepare npm@latest --activate. Corepack downloads npm as a tarball into its own cache and atomically swaps the active version — no self-modification, so the arborist-version mismatch can't bite.

How we tested

Two consumers, four CI runs, all green:

Test	Consumer	Original pin	Run
A1	kunobi-ninja/mcp-installer	v6	26163934763 ✅
A2	same	same	26166771983 ✅
A3	same	same	26167167574 ✅
B	Zondax/cli	v7 (different major)	26166913260 ✅

• A1–A3: temporarily pinned kunobi-ninja/mcp-installer CI at this branch, ran it three times via empty-commit triggers. Three independent fresh runs — both checks-ts and the publish dry-run green every time. Rules out flakes in corepack's tarball download.
• B: did the same on Zondax/cli (different major, different package shape, has a separate Test Build Introspection matrix on top of publish). Throwaway draft PR opened and closed without merging; the publish job ran for 32s and passed. Confirms the fix isn't accidentally coupled to mcp-installer's specifics.
• The runs collectively exercised every step of _publish-npm.yaml except npm publish --provenance (the actual upload — gated by if: !inputs.dry_run). After the corepack swap the resulting npm binary is the same tarball npm@latest produces directly, so the publish path is behaviourally identical to before.

Sequence

After merging:

• Decide whether to forward floating major tags (v6, v7, v8, v9) so existing consumers pick up the fix without changes.
• Or tag a new minor/major and require consumers to bump explicitly.

Related: Zondax/kunobi-frontend#1672 (the downstream feature work whose CI surfaced this), kunobi-ninja/mcp-installer#1 (currently blocked on this PR).