Fix publish and release pipelines

[vmoroz]

Fix publish and release pipelines

Two unrelated breakages were blocking releases.

publish.yml — ESRP rejects .node files

Microsoft.JavaScript.NodeApi.node is a native module — a PE/COFF DLL
with a non-.dll extension. ESRP's PendingAnalysis stage cannot handle
that extension and fails after a 30-minute hang.

Fix: rename .node → .dll before ESRP, sign through the existing
**/Microsoft.JavaScript.NodeApi.dll glob, rename back after.

Also bumped EsrpCodeSigning@5 → @6 (two call sites).

release.yml — PAT-based service connections no longer permitted

The Nuget - ms/react-native-public and Npm - ms/react-native service
connections authenticate via PAT, which policy now forbids. Managed
Identity is mandatory.

Fix: before each publish, an AzureCLI@2 step fetches an AAD token
for the AzDO resource (499b84ac-1321-427f-aa17-267ca6975798) under MI
and overrides the service connection's auth at runtime via
##vso[task.setendpoint id=<guid>;field=authParameter;key=apitoken].
1ES.PublishNuGet@1 and npmAuthenticate@0 then run unchanged and
transparently use the MI-derived token.

Notes:

• Why the inline override? ADO does not allow MI-based auth on
  service connections, so the connection itself still has to be
  configured with a PAT. The override-at-runtime pattern is the only
  way to actually publish under MI today; the stored PAT is bypassed
  on every build. This is the long-term shape unless ADO changes.
• Temporary MI subscription. Office-Hermes-Windows-Bot is used
  because the official Office-Node-Api-DotNet-Bot MI does not yet
  have the right permissions on these feeds. Switch back once it does.

Drive-by

• release.yml: renamed CustomPipelineTemplates →
  OfficePipelineTemplates and dropped the
  ES365AIMigrationTooling-BulkMigrated-Release legacy build tag.

Test runs

• Publish: https://dev.azure.com/office/ISS/_build/results?buildId=49400440&view=results
• Release: https://dev.azure.com/office/ISS/_build/results?buildId=49406519&view=results

[jasongin]

There is already another file named Microsoft.JavaScript.NodeApi.dll in this directory - it is the managed assembly DLL that the unmanaged .node file loads after boostrapping .NET. So it looks like this rename will overwrite that file and the final build output will not be correct.

[vmoroz]

Good catch! I will fix it.