azdo-pipelines: bootstrap pnpm from proxy feed instead of Corepack

[bwateratmsft]

Problem

pnpm builds on network-restricted Azure DevOps agents fail at the "👉 Activate pnpm" step. Corepack downloads the pnpm binary from registry.npmjs.org before any feed auth / .npmrc is applied, and those agents cannot reach that host (hard network block, EPERM).

Fix

In azdo-pipelines/templates/setup.yml, install the pinned pnpm via npm install -g pnpm@<version> from an anonymous proxy feed (https://packagefeedproxy.microsoft.io/npm) instead of Corepack. npm fetches only the packument + tarball, both of which the proxy serves (verified: packument and tarball return 200; the per-version manifest endpoint that COREPACK_NPM_REGISTRY needs returns 404, which is why the Corepack env-var route does not work with this feed).

• The pinned version is parsed from package.json's packageManager field (pnpm@11.8.0 or pnpm@11.8.0+sha512... → bare version), so consumers keep a clean "packageManager": "pnpm@<version>" — no tarball URLs or extra env vars.
• corepack disable pnpm runs first so a stale Corepack shim can't shadow the freshly installed global pnpm on PATH.
• The proxy feed is hardcoded for now; it can be parametrized later if a consumer ever needs a different one.

The packageManager: pnpm doc comment in 1es-mb-main.yml and the "Using pnpm" section in azdo-pipelines/README.md are updated to match.

Scope

• GHA reusable workflow (.github/workflows/jobs.yml) is unchanged — it stays on Corepack. GitHub-hosted runners reach registry.npmjs.org, and once a consumer reverts to a clean pin its GHA works via Corepack. The (possibly network-scoped) proxy is deliberately not baked into the public-runner path.
• AzDO consumers pin these templates at ref: azext-pt/v1, which is advanced to this commit separately (via the fast-forward GHA) after merge.

Consumer follow-up (e.g. vscode-containers)

Once this lands and azext-pt/v1 is advanced:

• Revert package.json packageManager to a clean pnpm@11.8.0 (drop the proxy tarball URL + #sha512 integrity form).
• Remove the COREPACK_ENABLE_UNSAFE_CUSTOM_URLS=1 AzDO pipeline variable.
• No new pipeline parameter needed — the feed is hardcoded in the template.

Validation

• YAML parse-checked all edited files.
• AzDO pipeline behavior is validated by re-running the consumer build after azext-pt/v1 is advanced.