Keep the GitHub Packages token out of the committed .npmrc

[duguankui]

The bug

angular/.npmrc referenced ${PACKAGES_READ_TOKEN}. Any ${...} placeholder in a committed .npmrc makes every yarn invocation in that directory fail hard when the variable is unset:

error Error: Failed to replace env in config: ${PACKAGES_READ_TOKEN}

That includes yarn start, yarn build and yarn test — none of which touch the private registry. Reported from a plain ./start.ps1.

The fix

• angular/.npmrc keeps only the two scope mappings and no credential.
• Both workflows write the token to ~/.npmrc in a new Authenticate to GitHub Packages step. That also removes the job-level env: from both, and with it the "must be job-level because setup-node's cache: yarn probe reads .npmrc before any step" complication — with no placeholder to expand, the probe has nothing to fail on.
• The file documents the one-time local setup. Worth knowing: the token needs read:packages; a plain repo-scoped one (which is typically what's sitting in $GITHUB_TOKEN) is not enough and would have failed at download time instead.
• Drops //npm.pkg.github.com/:always-auth=true. With both scopes mapped, yarn attaches the token to the tarball download without it, and npm 11 warns on every invocation that the per-registry form is unknown config.

Test plan

• Reproduced the reported failure, then re-ran the same ./start.ps1 path with no token variable set — clean, and the npm always-auth warning is gone too
• Cold-cache yarn install --frozen-lockfile (YARN_CACHE_FOLDER pointed at an empty dir, credential in a user-level .npmrc) — succeeds, all four packages at 10.0.0-rc.16
• Same cold-cache run with and without always-auth, to establish it isn't load-bearing
• CI on this PR exercises the new authenticate step end to end

[duguankui]

Superseded by #64. That PR removes the need for a GitHub Packages credential altogether — flex-fields 10.0.0-rc.16 is now on public npmjs, so angular/.npmrc carries no token placeholder and no authenticate step to replace it with. The local-dev breakage this PR fixed is fixed there too, by deletion rather than relocation.