ci: publish npm packages through ESRP

[Saadnajmi]

Summary

Migrate the Azure DevOps npm release path from token-based yarn npm publish to
Microsoft ESRP while preserving the original RNM publishing shape.

• Keep one original-style NPM stage and the existing
  .ado/jobs/npm-publish.yml template.
• Pack dynamically discovered public workspaces in a normal job, then consume
  the pipeline artifact from a dependent 1ES production release job in the
  same stage.
• Replace PowerShell release checks with directly invoked Node/TypeScript
  helpers.
• Copy the ESRP identity inputs verbatim from
  microsoft/node-api-dotnet@04a65d25 rather than referencing undefined
  $(Esrp*) variables.
• Use one npm tag per release line and remove npm-token/additional-tag handling.

Original-contract build behavior

The parent publish job ran yarn install, release configuration, and workspace
yarn npm publish. It did not run root yarn build or yarn build-types.

The revised pack job therefore runs only:

yarn workspaces foreach --all --topological --no-private run build

This preserves RNM's original package contents while building
react-native-macos-init, whose existing package contract expects generated
CommonJS output.

Corrected package parity

Earlier PR evidence incorrectly treated
450d3dd494b8db00d706f908cc952d8bee147a77e055ad5ba4f6d207d5685210
as the canonical RNM tarball. That artifact was contaminated by an extra
yarn build-types step that the original publish job never ran.

Clean package-parity reproductions using Node 22.22.0 and Yarn 4.12.0 on both
main and 0.83 establish the original-contract hashes:

• react-native-macos:
  73c592e775d773d246d7a9c7dc3569012d3a5e29b7d62f7857cf8a2c9e02d558
• react-native-macos-init:
  546371a1931e2a54891afb836b14d3d7f58b28c538a4d6f9a6b5b60d7cbfe7de

Original and revised RNM tarballs are byte-identical. Their extracted contents,
modes, manifests, tar headers, and member order also match. Both clean runs
contain zero package/types_generated/ entries.

Two additional independent clean main reproductions produced the same RNM
bytes, proving the hash does not depend on retained generated state.

The stale 450d... artifact differs only by 230 generated declaration files:
all 4,365 common members are content- and metadata-identical. The published
react-native-macos@0.81.9 tarball independently contains zero
package/types_generated/ entries among 4,194 members, corroborating the
original published contract.

Release behavior

• Main remains a no-op because nightly publishing is disabled.
• Current/latest and promoted release lines publish with latest.
• Older stable lines publish with their branch/minor stable tag.
• Release candidates publish with next.
• Already-published exact package versions are removed before ESRP, making
  partial retries idempotent.

Validation

• 8 focused Node tests passed.
• Targeted Prettier, ESLint, direct TypeScript, YAML parsing, changeset status,
  and git diff --check passed.
• Static pipeline checks prove one NPM stage, NpmPack followed by
  NpmEsrpRelease, and an ESRP condition requiring unpublished packages.
• The revised release path contains no PowerShell, npm token, additional-tag,
  root-build, or build-types path.
• Main no-op and empty filtering were exercised directly.
• Full closed 1ES expansion cannot be run outside Microsoft's private pipeline
  environment; the same-stage release-job artifact shape follows existing
  public 1ES pipeline precedents.

Follow-up rollout

After independent review and main landing, backport this commit directly to
0.83-stable. Recreate the 0.84-0.87 release stack so those branches inherit
the main change once through ancestry rather than duplicate cherry-picks.

[tido64]

What is this parameter for?

[tido64]

If you're not processing anything in parallel, sync variants are easier to read and maintain.