Lift the previous `UnsupportedPeerDependency` upfront guard and
replace it with the real peer check from upstream's
`getNodeHoistInfo`. The hoister now accepts lockfiles whose
packages declare peer dependencies and produces the layout pnpm
would: a peer-constrained dep only floats up to the root when
doing so doesn't change which package its peers resolve to.

Mechanics:

- `HoisterResult` carries the input `peer_names` set forward.
  Upstream's `HoisterResult` doesn't (the peer set lives on its
  intermediate `HoisterWorkTree`); pacquet runs the algorithm on
  `HoisterResult` directly, so the peer set has to ride along.

- The BFS queue now carries an ancestor `Vec<Rc<HoisterResult>>`
  per entry. Each child's path is the parent's path plus the
  parent itself. The ancestor chain is what `would_shadow_peer`
  walks back when deciding whether a candidate hoist would
  change its own peer resolution.

- New `AbsorbDecision::PeerShadow` variant alongside `Free`,
  `SameNode`, `Conflict`. Fired when:
    1. Root declares the candidate's own name as a peer
       (root-shadow guard — vacuous today since the wrapper's
       `.` root has empty `peer_names`, kept for parity).
    2. For each peer name `P` the candidate declares, the closest
       ancestor providing `P` does so with a different ident than
       the root's `P`. Promoting the candidate would silently
       re-resolve the peer.

- The previous `UnsupportedPeerDependency` error variant and
  `find_first_peer_constrained` scan are gone. The `non_exhaustive`
  enum tag stays so future variants can be added without breaking
  callers.

DAG-vs-tree caveat: upstream's `cloneTree` duplicates the work
tree into a strict tree per parent path, so each candidate visit
has a unique ancestor chain. Pacquet preserves the DAG and
records only the path the BFS actually used. In the rare case
where the same `Rc` is reachable through both a peer-compatible
and a peer-shadowing path, pacquet refuses to hoist; the layout
is at most over-nested, never under-nested. Documented on
`would_shadow_peer`.

Tests:

- `peer_constrained_node_stays_under_parent_when_root_provides_different_ident`
  — `app → widget (peer: react) + react@17`, `root → react@18`.
  widget cannot hoist because hoisting changes its peer to
  react@18.
- `peer_constrained_node_hoists_when_ancestor_and_root_agree` —
  same shape but `app → react@18` matches root's `react@18`
  (shared Rc via wrapper dedup), so widget hoists freely.
- All 10 pre-existing tests still pass; the previously-failing
  `peer_dependency_in_lockfile_surfaces_unsupported` test is
  replaced by the two above.

Upstream reference: `yarnpkg/berry@4287909fa6` `hoist.ts:414`
(root-shadow) and `:454-479` (ancestor-path peer check).

…461 review)

Two review findings:

1. **Stale ancestor path in BFS.** The previous loop captured each
   queue entry's `ancestor_path` at enqueue time. When an
   intermediate node was hoisted to root between being queued and
   being dequeued, the path baked into the queue entry still
   listed its former parent's siblings as ancestors. `would_shadow_peer`
   then walked ex-ancestors and over-refused legitimate hoists.

   Replace the BFS with a recursive `hoist_subtree`: the path
   passed into each recursion is computed *after* the parent's
   hoist decision has been applied. A child that was just moved
   to root recurses with path `[root]`; a child that stayed
   nested recurses with `parent_path + [parent]`. Either way the
   path reflects the node's current position when its own
   children are evaluated.

2. **Misleading comment** in `would_shadow_peer`'s "ancestor has
   no provider" branch — said "the BFS will visit the candidate
   again" but the `visited` set explicitly prevents re-visits.
   Reword to describe what the branch actually does (walk further
   up looking for the real provider; if none exists, no shadow).

The `VecDeque` import drops out with the BFS body.

New regression test
`peer_check_uses_post_hoist_ancestor_path_not_queue_time_path`
pins the fix: a deep chain (`root → app → mid → terminal`,
peer: react) where `mid` hoists to root past a conflicting
`app.react@17`. Under the previous BFS the stale path
`[root, app, mid]` made `terminal`'s peer check trip on
`app.react@17 ≠ root.react@18` and refuse the hoist; under DFS
the actual path `[root, mid]` finds no provider mismatch and
`terminal` correctly flattens to root.

All 13 tests pass (10 pre-existing, 2 from the initial 3c push,
1 new regression). `just ready`, `cargo doc
--document-private-items`, `taplo format --check`, `just dylint`
clean.