ci: sync e2g-pypkg 1.0.2 and add coverage badge

[alanwilter]

Summary

Updates the cruft template to e2g-pypkg 1.0.2 and refreshes the lock file. The main addition is a coverage badge in the README. CI generates it and commits it to the repo, so it needs no third-party service.

Changes

Coverage badge

• New .github/workflows/coverage-badge.yml. It runs after every successful CI run on main, reuses that run's coverage-3.12 artifact, renders assets/coverage.svg with genbadge, and commits it if it changed.
• assets/coverage.svg starts as the template's 0% placeholder. The merge of this PR should replace it with the real figure.
• .gitignore gains an exception so the badge isn't caught by the existing *.svg rule.

README

• Adds the template's badge row, minus the semantic-release badge.
• Removes the "How releases work" section. It described python-semantic-release and contradicted the tag-based "Releasing" section. Its Conventional Commits guidance moves to "Development".
• Updates the project tree for the new workflow and assets/.

Template sync

• justfile: the pdb recipe forces -n0, since pdb doesn't work under xdist.
• .cruft.json: now points at e2g-pypkg 1.0.2.

Dependencies (separate commit)

• Relocked with the 7-day cooldown: 49 upgrades and 2 new transitive packages.
• opencv-python appears in the lock only under an emscripten marker, so on Linux and macOS only opencv-python-headless is installed.
• The lockfile format moved from revision 3 to 5.
• pyproject.toml only re-sorts keywords and URLs and lists dependency groups explicitly. Neither change affects behaviour.

Where this deviates from the template

The template releases via python-semantic-release on every push to main. PyeScan releases when a version tag is pushed. Taking the template as-is would have broken things here, so:

• CI still runs on pushes to main. The template skips them because its release job runs CI on main. Our release job only runs on tags, so skipping would leave main with no CI at all.
• The badge job lives in its own workflow, triggered by workflow_run. The template puts it in release.yml, which here only runs on tags. It also can't go inside ci.yml: release.yml calls ci.yml with read-only permissions, and GitHub rejects a called workflow whose job asks for contents: write.
• No [tool.semantic_release] config. It would be dead config.
• release.yml is unchanged, and now excluded from template updates. The template's changes to it are all semantic-release specific, so .cruft.json lists it under skip and future cruft update runs leave it alone. The README's "Template updates" section records why.
• Templates 1.0.1 and 1.0.2 are taken as reference bumps only. 1.0.1 moves to semantic-release v10 and adds allow_zero_version to [tool.semantic_release]. 1.0.2 adds a semantic-release build_command that writes the new version into uv.lock in the release commit. None of it applies here. The problem 1.0.2 fixes is already covered: the documented uv version X step updates pyproject.toml and uv.lock together, and a hand-edited version with a stale lock fails uv sync --locked in the release workflow's CI job, before anything is published. Future template changes to [tool.semantic_release] will still appear as rejected pyproject.toml hunks and can be discarded.

Testing

• ruff format --check and ruff check pass.
• pytest: 119 passed, coverage 42.91% against the 40% floor.
• uv lock --check passes.
• actionlint passes on all three workflows.

The badge workflow can't be exercised from this branch. GitHub only runs workflow_run workflows from the default branch, so the merge will be its first real run.

For reviewers

• Branch protection: if main requires pull requests, the badge commit from github-actions[bot] will be rejected. It would need a bypass for that actor.
• uv version floor: required-version is still >=0.12.3,<0.13, but the lock was written by uv 0.12.23 at revision 5. I haven't confirmed the oldest uv that reads revision 5. If it's newer than 0.12.3, the floor should go up. CI is unaffected because setup-uv installs the latest uv.
• Workflow name coupling: the badge workflow finds CI by its name: CI. Renaming that workflow would silently stop the badge from updating.

🤖 Generated with Claude Code