Relock uv.lock after the version bump, and run CI on develop pushes

[thc1006]

develop is red right now, and so is every pull request based on it.

a086ca6 raised the version to 0.1.0 in pyproject.toml without relocking, so uv.lock still records 0.0.1 for this package:

pyproject.toml:7   version = "0.1.0"
uv.lock:445        version = "0.0.1"

uv lock --check fails on that, which is the step #62 added and it is working as intended. The fix is one line.

I confirmed it is develop itself rather than anything downstream: checking out develop's files into a clean tree and running uv lock --check fails the same way.

Why nobody saw it

The workflow triggers on push: branches: [main] and on pull_request. A direct push to develop runs nothing at all, so a commit can sit there red until the next pull request inherits it.

The second commit adds develop to the push trigger. Drop it if you would rather keep the trigger as it is; the relock alone unblocks everything.

I had written that this adds no duplicate runs. That is true for a pull request targeting develop, and wrong for one whose head is develop, which is exactly what #61 is. A push to develop will now produce both a push run and a synchronize run for #61. They are not the same tree, since the pull request run tests develop merged into main, and the concurrency key is on the ref so neither cancels the other. Worth the extra run rather than something to suppress, but the claim was too broad and the commit message now says so.

After this merges

The other open pull requests will not go green on their own. pull_request fires on head changes, not base changes, so their existing red runs stay as they are until each head branch is updated, rebased, or the pull request is reopened. Re-running the old job does not help either, since it pins the merge commit that was computed against the broken base.

#61 is the exception: develop is its head, so merging this updates it directly.

@zuorenchen this one is worth taking ahead of the other open pull requests, since none of them can go green until it lands.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[thc1006]

Took all three points; they were all mine to fix and none needed a code change.

The workflow comment now describes the lasting reason rather than the state before the change, and no longer points at a lockfile that is not in that file. The no-duplicate-runs claim is corrected in both the commit message and the body: it holds for a pull request targeting develop and not for one whose head is develop, which is #61. The body now also says that merging this will not turn the other pull requests green by itself, since pull_request fires on head changes rather than base changes.

One premise worth recording as checked rather than assumed: the note about #75 renaming Tests and coverage and possibly breaking a required check does not apply here. This repository has no branch protection and no rulesets on either main or develop, so nothing is bound to a check name today. Worth revisiting if protection is ever turned on, which is a separate and probably good idea.