Check uv.lock and plugins/uv.lock freshness in just check and CI

[strickvl]

What this changes

Adds a just lock-check recipe that runs uv lock --check for the root project and for plugins/. It is wired into two places:

• just check, as the first step, so it fails locally before anyone pushes.
• The CI lint job in .github/workflows/ci.yml, as a new just lock-check step.

Why

Every dependency install in CI and in the justfile uses uv sync --frozen. --frozen installs exactly what the lock file says and never compares it to pyproject.toml. So when a PR changes a dependency range and forgets to regenerate a lock file, nothing on that PR fails.

That is what happened in #1250: the root SQLAlchemy range changed, plugins/uv.lock was not regenerated, and plugin CI kept testing on SQLAlchemy 2.0.51 while core tested on 2.1.1. #1257 fixes that lock file.

The only existing comparison is in release.yml ("Prepare development reset"), which runs after a release has already been published. The stale lock would have failed there, in front of whoever was cutting the release, long after the PR that caused it.

Reviewer Notes

This PR is stacked on #1257. Its base is fix/plugins-lock-sqlalchemy, not develop, because the new check fails on develop today (that failure is the bug #1257 fixes). Review and merge #1257 first; GitHub then retargets this PR to develop.

The change is small. The two things worth a look:

• Where the CI step sits. ci.yml does not call just check; the lint job lists recipes one by one. So adding the recipe to just check alone would not have reached CI, which is why there is an explicit just lock-check step. I put it in lint because that job already has uv and just set up and runs on every non-draft PR.
• Whether the check can fail by itself over time. Both pyproject.toml files set exclude-newer = "3 days", a rolling window. I checked that this does not make the check flaky: the lock files record the window as a duration (exclude-newer-span = "P3D"), not as a date, and uv lock --check keeps an existing pin as long as it still satisfies pyproject.toml. A newer release appearing on PyPI does not fail it. The root lock in this branch was last regenerated in Validate SQLAlchemy 2.1 server compatibility #1250 and still passes.

lock-check does not need the project environment installed, so it adds a few seconds at most.

Reproduction

On this branch the check passes:

just lock-check

To see it catch the original bug, put develop's stale lock file back and run it again:

git show origin/develop:plugins/uv.lock > plugins/uv.lock
just lock-check

Expect error: The lockfile at uv.lock needs to be updated, but --check was provided. and a non-zero exit from the uv lock --project plugins --check line. Restore the file afterwards:

git checkout -- plugins/uv.lock

(Once #1257 is on develop, origin/develop no longer has the stale file; use 720a52913:plugins/uv.lock instead.)

Local checks run

just check passes with the new step. actionlint, yamlfix and just zizmor report nothing. The two test files that read the workflow or justfile pass (108 tests). I did not rerun the full just test suite: no Python code or dependency changes here.

No changelog fragment: contributor tooling only.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-05T11:31:16.828261Z	3c544cb	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[AlexejPenner]

🦭