feat: "Pin to locked version" code action for all supported registries

[rassie]

Closes #121.

Summary

Adds a "Pin to locked version" code action that pins a dependency in the manifest to the version actually resolved in the workspace's lock file.

Supported lock files (one resolver per format, registered per registry):

Registry	Lock files (priority order)
crates.io	Cargo.lock
npm	pnpm-lock.yaml > yarn.lock (v1 + Berry) > package-lock.json
PyPI	uv.lock > poetry.lock > pdm.lock > Pipfile.lock
JSR	deno.lock (v3 + v4)
pnpm cat.	pnpm-lock.yaml

When multiple lock files coexist in a workspace, the more specific package manager wins — a repo with both pnpm-lock.yaml and package-lock.json pins against pnpm.

Design notes

• LockResolver trait (src/version/lock.rs) is registered per PackageResolver and runs only on a code-action request — it does not participate in the diagnostics pipeline.
• format_pinned_spec (src/lsp/code_action/lock.rs) is exhaustive over RegistryType, so adding a new registry breaks the build until its pinning contract is decided. The case table locks the contract per registry: bare version for npm / pnpm-catalog / crates / JSR / GitHub Actions / Docker, ==<v> for PyPI (PEP 508 embeds the operator), v<v> for Go (idempotent on already-prefixed input).
• Cargo / uv / poetry / pdm share a [[package]] TOML scanner (extract_package_version_from_toml_lock).
• Yarn handles both v1 (quoted-block) and Berry (YAML-ish) dialects, multi-spec keys ("lodash@^4, lodash@^4.17"), and strips Berry's peer-dep dedup suffix (18.2.0_react@npm:18.2.0 → 18.2.0).
• Pipfile.lock stores "==1.2.3" — the resolver returns bare 1.2.3 so PyPI's format_pinned_spec re-adds the operator centrally.
• Deno: strips peer-dep suffix from specifiers keys, scans both lock v3 and v4 formats.

The branch is split into 11 commits — one per lock format plus scaffolding and a rebase fixup for the new RegistryType::Docker variant introduced on main — so each can be reviewed in isolation.

Test plan

• cargo test — 14 new e2e tests in tests/e2e_lock_pin.rs (one per format + omit-cases + priority tests) plus unit tests in each locks/*.rs
• cargo fmt -- --check
• cargo clippy --all-targets
• Manual smoke test in editor — verified for uv.lock and package-lock.json; the other formats are covered by e2e tests but not yet by manual editor testing

[skanehira]

@rassie I fixed security audit failure
#130

[rassie]

Thanks! Rebased, waiting on #128.

[skanehira]

Two design concerns around lock-file scoping — please see inline.

[skanehira]

This iterates every importer and returns the first match, but the workspace path is discarded. In a pnpm monorepo where the same package is pinned to different versions across workspaces, this returns the wrong version for any manifest that isn't the first one in iteration order.

Repro

repo/
├── pnpm-lock.yaml
└── packages/
    ├── app-old/package.json   # "react": "^17.0.0"
    └── app-new/package.json   # "react": "^18.0.0"

# pnpm-lock.yaml
importers:
  packages/app-old:
    dependencies:
      react: { specifier: ^17.0.0, version: 17.0.2 }
  packages/app-new:
    dependencies:
      react: { specifier: ^18.0.0, version: 18.2.0 }

Requesting the code action on react inside packages/app-new/package.json currently surfaces Pin to locked version: 17.0.2 (whichever importer iterates first), not 18.2.0.

Suggestion

Compute the manifest's path relative to the lock file's directory and look up that importer first:

let lock_dir = lock_path.parent();
let importer_key = manifest_path
    .parent()
    .and_then(|p| p.strip_prefix(lock_dir).ok())
    .map(|p| if p.as_os_str().is_empty() { ".".into() } else { p.to_string_lossy().replace('\\', "/") });

Then try importers[importer_key] first. Falling back to other importers is debatable — being strict (return None when the matching importer doesn't list the package) is probably safer because a fallback can again surface a wrong version. Either way, the workspace path needs to participate in the lookup.

[skanehira]

The walk continues all the way to / (or C:\\). If a developer keeps multiple unrelated projects under a shared parent that happens to contain a stray lock file, we'll resolve against it.

Repro

~/work/
├── Cargo.lock              # leftover from an old experiment
└── unrelated-project/
    └── Cargo.toml          # no Cargo.lock of its own

Opening unrelated-project/Cargo.toml makes find_lock_file walk past the project root and pick up ~/work/Cargo.lock, producing pin suggestions for crates the project doesn't even use.

It's also a non-trivial amount of stat syscalls on deep paths every code-action request, which compounds with the per-resolver loop noted elsewhere.

Suggestion

Stop the walk at the project boundary. Two reasonable signals (in priority order):

1. .git directory — the most reliable VCS-root marker; covers the overwhelming majority of repos.
2. Workspace root sentinel — e.g. presence of pnpm-workspace.yaml, Cargo.toml with [workspace], etc.

Something like:

loop {
    let candidate = dir.join(lock_filename);
    if candidate.is_file() {
        return Ok(Some(candidate));
    }
    if dir.join(".git").exists() {
        // VCS root reached; do not escape the repo.
        return Ok(None);
    }
    if !dir.pop() {
        return Ok(None);
    }
}

.git exists as either a directory (normal repo) or a file (worktree / submodule), so .exists() is the right check. If we want to support repos without .git (rare in practice), we can add a hard cap (e.g. 16 ancestors) as a backstop.