fix(validation): cache npm dependencies in validation and RA workflows

[hdamker]

What type of PR is this?

bug

What this PR does / why we need it:

Neither reusable workflow requested an npm cache, so every validation job cold-fetched all 297 validation dependencies from the npm registry. When the runner-to-registry path degraded on 2026-09-04, npm ci stalled for up to five minutes per run across every API repository — measured on ReleaseTest as ~44s average wall time before, ~206s during — while still concluding success, so it degraded time-to-validate rather than correctness. This adds cache: npm to both setup-node steps that feed the shared run-validation action, and trims the install invocation.

• Repeat runs restore the npm tarball store instead of re-fetching from the registry, removing the registry from the hot path whenever the cache is warm.
• Release automation's pre-snapshot validation gets the same treatment; it invokes run-validation through its own setup-node step.
• --no-audit --no-fund drop two round trips that produce no signal in CI; --prefer-offline uses the restored cache rather than revalidating.

Which issue(s) this PR fixes:

None — reported and diagnosed directly against the run history.

Special notes for reviewers:

cache-dependency-path differs by prefix between the two workflows because they check tooling out under different paths. tooling-ci.yml already uses this pattern for its own npm jobs.

Two limits: the cache is scoped to the calling repository, since GitHub runs a called reusable workflow's job in the caller's execution context, so each consuming repository warms its own entry and still pays one cold install after a lockfile bump or a cache eviction. And the request that stalled was never identified from the logs — the tarball store is the likely site for a lockfile-driven npm ci, but that is inference. Prebuilding dependencies would remove the registry entirely and remains available if this recurs.

The change cannot be exercised from a fork branch, since callers pin the workflow file at a ref in this repository. After merge the validation path is covered by the regression canary, whose path filter includes both changed locations; the release-automation path has no canary coverage and needs one snapshot dispatch. actionlint passes locally with the argument set from tooling-ci.yml.

Changelog input

 release-note
Cache npm dependencies in the validation and release-automation reusable workflows, so validation runs no longer cold-install all Node dependencies from the registry on every run.

Additional documentation

This section can be blank.

docs

[hdamker]

@rartych @Kevsy to planned after v0.10.0 release, potentially as 0.10.1 if the regression in ReleaseTest (and CommonalitiesTest) will show a significant improvement.