`uv check --script` currently ignores a direct `ty` dependency from PEP
723 metadata when choosing the checker. The script environment contains
the locked package, but uv still selects a standalone `ty` from its
built-in compatible range, so the checker can differ from the script’s
dependency graph.

This extends `Lock::dependency_selection` to include applicable
lock-manifest requirements. When a script directly declares `ty`, `uv
check` now runs the marker-selected locked package from the script
environment, preserving its source and transitive dependencies without
another resolution.

This is a followup to #19884 and it depends on #19982.

…#20078)

`Lock::dependency_selection` selects the exact locked package for a
direct project dependency, but the result currently discards
information, like selected extras or dependency-group conflict context
(used to select conflict forks). This isn't critical for our current use
cases (ruff and ty), but it's worth fixing to avoid future confusion.

For a relatively contrived example, a workspace may use a local build of
`ty` that depends on `a`, with two mutually exclusive groups pinning
`a==1` and `a==2`. With `uv check --no-sync`, uv selects the correct
locked `ty` for the enabled group, but previously discarded that group
context when building the cached environment. The marker on `ty`’s
dependency still referred to the project conflict outside the synthetic
tool subgraph, so materialization failed instead of selecting the
corresponding `a` fork.

This PR returns a `SelectedDependency` containing the exact package, the
union of extras from applicable direct edges, and the production or
dependency-group context. `Lock::to_resolution_from_dependency` passes
that information into the existing locked-subgraph traversal, activating
selected extras and resolving project conflict items even though the
project itself is outside the cached subgraph.

This is a follow-up to #19982 and #19989.