[potsrevennil]

Dependabot can't update lazy-lock.json, and :Lazy sync moves every plugin to its branch head, which is what made #49 a 16-plugin bump. This adds a weekly workflow that moves plugins only when upstream cuts a release. It also fixes CI's plugin restore, which the workflow depends on, and shares the setup between the two workflows.

Release-only updates. lua/config/lazy.lua sets defaults = { version = "*" }, so plugins with semver tags resolve to releases. .github/scripts/lazy-update.lua updates only plugins whose target is a newer release and labels each bump patch / minor / major in the PR body. Plugins with an explicit branch, version = false (nvim-cmp) or no tags stay at their locked commit. lazy-update.yml runs Mondays at 07:00 UTC: it smoke-tests the result, opens or refreshes one chore/lazy-update PR, and starts CI on it with workflow_dispatch, since PRs opened with GITHUB_TOKEN don't trigger workflows.

CI restore fix. A bare Lazy! restore on a fresh runner doesn't reproduce the lockfile. lazy.nvim's first-run install handles LazyVim before the plugins its specs import are known, rewrites the lock without them, and installs those at their upstream target. On master today, a fresh restore leaves 6 plugins off their locked commits; CI only gets it right on a warm cache. The restore now installs first, puts the committed lock back, restores, and cmps the result.

Shared setup. .github/actions/setup-kapi-vim builds the package, puts nvim on PATH, handles the plugin cache and runs the checked restore. ci.yml's test job and lazy-update.yml both call it. It's a composite action rather than a reusable workflow because lazy-update runs its update step between the restore and the smoke test.

• Look at: the forward-only rule in lazy-update.lua. Most plugins are locked past their last tag (plenary's last release is from 2023), so "latest release" would be a downgrade. A release the locked commit already contains is skipped; releases cut from a separate branch (neo-tree's v3.x) are compared by version.
• Look at: the cache split in the action. cache/restore plus cache/save let lazy-update read CI's cache with save-cache: 'false', so bumped plugins are never stored under the old lockfile's key. The save runs straight after the checked restore. The key changes from matrix.runs-on to runner.os/runner.arch (an action can't see the matrix), so expect one cache miss.
• Look at: lazy.nvim internals. The script uses lazy.manage.git, lazy.manage.semver and plugin._.updates, not a public API, so a lazy.nvim update can break it. It then fails at the check or update step rather than writing a bad lockfile.
• Verify:
  • Against this lock, the script finds no releases ahead of the locked commits, so nothing moves.
  • With flash rolled back to v2.0.0 and neo-tree to v2.71, it bumps flash to v2.1.0 (minor) and neo-tree to 3.42.0 (major), and only those two entries change.
  • The restore cmp passes on both a cold and a warm cache.
  • After merge: Actions → lazy.nvim updates → Run workflow.
• Out of scope: GitHub Actions version bumps.

Stacked on #49. Includes what was #54 (restore fix) and #57 (shared action).

🤖 Generated with Claude Code