ci: the lockfile's copy of the version is checked too

[Shashankss1205]

The drift

ci.yml's lint step checks that pyproject.toml and grapharc.__version__ agree, and its comment says why: if they drift, pip show and import disagree about what is installed.

There is a third copy. uv.lock carries an entry for this project, and it drifted:

[[package]]
name = "grapharc"
version = "0.1.5"     # pyproject.toml and __init__.py both say 0.1.7

Both 0.1.6 and 0.1.7 shipped that way — nothing re-locked after the version bump, and no job looked.

The fix

uv lock corrects the stale line (one line, in this PR). The guard is the part that matters: the lint step now parses uv.lock as well and refuses a mismatch, naming uv lock as the remedy. It also refuses anything other than exactly one grapharc entry, so a rename cannot make the check silently vacuous instead of failing.

Severity, honestly

Milder than the other two copies. A stale version in the lockfile misreports the project to someone reading the lockfile and to uv sync --locked; it does not reach an installed import the way a bad __version__ would. But it is the same class of bug as the one that step already guards, and a version declared in N places drifts in N−1 of them.

Verification

• The new check passes on this tree.
• It is red against main's lockfile — "uv.lock says '0.1.5' but pyproject says '0.1.7'" — which is the drift it exists to catch.
• ci.yml still parses.

Touches a different region of ci.yml than #116, so the two merge independently.

🤖 Generated with Claude Code