fix(ci): keep uv.lock in step with the release version bump

[vishal-bala]

The release job bumps version in pyproject.toml but commits only that file, so uv.lock — which carries the project's own version — goes stale after every release, and the next contributor to run make install picks up an unrelated bump in their PR. Nothing caught it: uv sync --frozen takes the lock as-is, and at tag v0.26.0 it installed redisvl==0.26.0 from a lock that still said 0.25.1.

The release job now bumps both files and verifies the edit before anything is committed or pushed: one changed line per file, and the new version on the redisvl entry specifically. It edits that one field rather than running uv lock, which re-serializes the whole file (258 lines of marker churn here) right after canary-build validated the old one. A new lock job in lint.yml runs uv lock --check so drift fails on the PR — note that a PR editing dependency specifiers without re-locking will now fail it; fix is uv lock.

---

Note

Medium Risk
Touches the auto-release job that commits to main and tags/publishes, so a bad sed or check could stall or mis-bump a release. Lock-check is otherwise low-risk CI.

Overview
Stops the release bot from leaving uv.lock stale after it bumps pyproject.toml. The project's own version in the lock is edited in place (not a full uv lock re-serialize), then checked: one version line per file, the redisvl entry specifically, and uv lock --check. Both files are committed together.

Lint CI gains a lock job that runs uv lock --check so dependency-spec changes without a re-lock fail on the PR. CONTRIBUTING notes that contributors should run uv lock when changing deps. This PR also aligns the lock's redisvl version to 0.26.0.

^{Reviewed by Cursor Bugbot for commit 53aa941. Bugbot is set up for automated code reviews on this repo. Configure here.}