fix(arborist): forward transitive overrides through linked store links (#9658)

In continuation of our exploration of using `install-strategy=linked` in
the [Gutenberg
monorepo](https://github.com/WordPress/gutenberg/pull/75814), which
powers the WordPress Block Editor.

Under `install-strategy=linked`, an override that forces a
**transitive** dependency to a version outside its dependent's declared
range was applied on disk but reported as `invalid` by `npm ls --all`,
which then exited 1 (`ELSPROBLEMS`). The hoisted strategy reports the
same edge as `overridden` and exits 0. The bug only surfaced when the
overridden package's dependent was itself a transitive (store) package —
a direct dependency of the root was handled correctly.

`npm ls` rebuilds the actual tree from the `.store` layout, and an
OverrideSet propagates down the tree through
`Link.recalculateOutEdgesOverrides`, which forwards the set from a store
symlink to its target node. A prior fix (npm/cli#9357) gated that
forwarding on a rule naming a **direct** dependency of the target, to
avoid flipping an unrelated target to "has overrides" and making `npm
ci` re-resolve lockfile-pinned edges. That gate was too narrow: a store
link whose own direct deps do not name the overridden package never
forwarded the set, so the chain to the deeper `dependent → overridden`
edge never received the rule and was reported `invalid`.

The fix walks the target's subtree (following resolved edges,
dereferencing links) and forwards the set when an override rule actually
applies to any reachable edge, matched via `getEdgeRule` on name and
spec so a non-applicable version-qualified rule still does not flip an
intermediate node. Because override propagation is event-driven during
load, a store link can run its check before its subtree is resolved;
`loadActual` therefore re-forwards through links once the tree is
complete, so the filesystem-scan path resolves transitive overrides as
`overridden` rather than `invalid`.

## References

Fixes #9619