fix(query): report logical dep location under linked strategy (#9656)

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`, `npm query ':root > *'` reported a
direct dependency at its `node_modules/.store/<key>/node_modules/<pkg>`
backing path instead of the logical `node_modules/<pkg>` location,
diverging from the hoisted strategy.

There are two root causes.
In `hasParent` (query-selector-all.js), a store-backing node is `isTop`,
has `resolveParent === root`, and has a top-level symlink whose parent
is root, so it matched as a direct child of root through the `linksIn`
logical-parent block that exists for workspaces.
This returned the store node alongside its logical `Link`.
In the `query` command, `QuerySelectorItem` read `node.target.location`,
which for a linked dep resolves to the store node.

The fix skips store-backing nodes in the `linksIn` parent check, so a
store node is reached only through its logical `Link` (matched via the
`edgesIn` branch) rather than as a direct child of root.
The `query` command now reports the node's own logical `location`/`path`
when the target is in the store, while workspaces and regular nodes keep
the target location (for example `packages/<ws>`).
Deduplication now keys on the target's physical location and ranks
competing representations of the same package, so a top-level placement
wins over the canonical store node, which wins over an internal store
symlink.
This keeps direct deps logical and transitive deps at their canonical
store key for selectors such as `:root *`, and leaves the hoisted
strategy unchanged.

## References

Fixes #9617