#8 Dependency version-update PRs (not just security fixes)

Summary

Today cave only opens fix PRs for security alerts (OSV match → speculative build → PR if green; see start-speculative-fix / process-pending-fixes in src/deps-fix.lisp). Dependabot also does version updates: keep dependencies current even when there's no advisory. We want that second mode.

Why it's harder than the security path

The security path is registry-agnostic: OSV tells us the fixed version, so we never query a package registry. Version updates require knowing the latest available version, which means querying each ecosystem's registry — and that is highly repo/environment dependent:

• Private registries: a repo may resolve Maven from a private Nexus/Artifactory, npm from a private registry, Python from a private index, Go via a corporate GOPROXY, etc. Querying public Maven Central would give wrong/irrelevant answers.
• Credentials: private registries need auth, which cave must store per-repo/org and never leak into logs or runner containers.
• Per-ecosystem "latest" semantics: Maven group:artifact metadata, npm dist-tags, crates.io, PyPI JSON, Go module @latest/proxy, and GitHub releases/tags (for GitHub Actions deps) all differ. Pre-release/RC filtering, version constraints, and "allowed update level" (patch/minor/major) matter.

Proposed shape

• Per-repo / per-org registry config (e.g. in .cave/deps.yml): for each ecosystem, the registry URL + credential reference (secret). Default to public registries when unset.
• A latest-version resolver per ecosystem that honors that config.
• Reuse the existing machinery: classify update → safe-bump-manifest → branch → speculative build → PR if green (same as security fixes), bounded by the existing automerge_ceiling / update-level policy in cave_org_dep_policy.
• Group/schedule (e.g. weekly) and de-dupe against open update PRs.

Notes

• Security fixes stay independent and always-on; version updates are opt-in per repo (they're noisier and registry-dependent).
• GitHub Actions deps (e.g. actions/checkout) resolve "latest" from GitHub tags/releases, not a package registry — another resolver.

Filed from the dependency-updates work; see docs/design/DESIGN_DEPENDENCY_UPDATES.md.