ci: shard tests and merge Vitest blob reports - #11233

Pass `--silent` to `vitest --merge-reports` so the `merge-test-reports` job does not replay console output from the tests. The shard jobs already print it.

The package isn't tested in CI and its tests currently fail. The `test` job now runs `vitest --shard` from the root, so it would pick up the package and fail the run. Leave it out of `projects`.

Set `VITEST_BLOB_LABEL` to the Node version in the `test` job. The label goes into each blob's filename and tags its test files, so reports from different Node versions no longer overwrite each other when merged. A single `merge-test-reports` job can now combine every blob, and the merged output shows which Node version a failure came from.

Add the `github-actions` reporter to the `vitest --merge-reports` step. Vitest enables it automatically only when no `--reporter` is passed, so our explicit `--reporter default` turned it off. The reporter writes a test report to `GITHUB_STEP_SUMMARY` and adds inline annotations for failures.

Each job spends about 25 seconds on setup, and the whole suite takes about 9 minutes of test time, measured on a sharded run. Doubling the shard count cuts the slowest shard from roughly 80 to 55 seconds. That is still about six times fewer jobs than the old one-job-per-package layout.

When a PR doesn't change any root files, the `test` job now writes a temporary
Vitest config that lists only the changed packages and their dependants, and
runs the shards against that. Full runs still use the root config. The `test`
job is skipped when no packages changed, and `merge-test-reports` is skipped
with it. `--passWithNoTests` stops shards that end up with no test files from
failing.

Running 20 shards for a PR that touches one package leaves most of them with
no test files, and each still pays for checkout and setup. Full runs keep 20
shards. Other runs use `min(changed packages, 18) + 2` shards, so between 3
and 20.

The shard step moves from `prepare-environment` to `prepare`, because it needs
the changed paths. The workflow also passes `--silent` to the test step.

Coverage thresholds are configured per package, and a package's files are
split over shards, so they can only be checked once the shard reports are
merged. The shards now run with `--coverage`, and the merge job runs
`--merge-reports --coverage`, which checks each package's thresholds against
the merged data.

`createRootConfig` in `scripts/lib/create-vitest-config.ts` builds the root
config for this. It loads each package's own Vitest config, prefixes its
coverage `include`, `exclude`, and `thresholds` with the package directory,
and only applies thresholds when merging. The root config and the temporary
config for changed-only runs both use it. Workspace paths come from Yarn
through `getAllWorkspaces`, which gains an `includePrivate` option so
`package-template` stays in the root projects.

Vitest loads `scripts/lib/create-vitest-config.ts` as part of a config, and a
config doesn't get the `tsconfig` path mapping that tests get. The import of
`@metamask/node-utils` therefore resolved to its build output, and failed with
"Failed to resolve entry for package" when the package wasn't built.

The helper now checks whether a config file exists with `access` from
`node:fs/promises`, and the tests mock that instead.

With coverage enabled, the slowest of the 20 shards takes about 170s while the
average takes about 95s, so the slowest shard sets how long the test phase
lasts. More shards shrink the slowest one. Full runs now use 30 shards, and
runs that touch only some packages use between 3 and 30.