Add automated release pipeline for scanner

[mgoldsborough]

Summary

• Consolidate scanner version to single source of truth (pyproject.toml) — __init__.py and scanner.py now derive version via importlib.metadata, Dockerfile uses SCANNER_VERSION build arg
• Add scanner-publish.yml: tag-triggered pipeline that verifies (ruff, ty, pytest), publishes to PyPI via trusted publishing (OIDC), and builds + pushes Docker image to ghcr.io/nimblebraininc/mpak-scanner
• Document release process in README and CLAUDE.md
• Add mpak.dev badge to README

Test plan

• uv run ruff check src/ tests/ — clean
• uv run ruff format --check src/ tests/ — clean
• uv run ty check src/ — clean
• uv run pytest -m "not e2e" — 114 passed
• Merge, tag scanner-v0.2.4, verify publish pipeline runs end-to-end

[JoeCardoso13]

Solid PR — clean CI/CD pipeline with OIDC trusted publishing, proper version derivation from git tags, and a well-structured multi-stage Dockerfile. Three minor nits below, none blocking.

---

MINOR-1 — Dockerfile ARG default will become stale
(apps/scanner/Dockerfile)

CI always passes --build-arg SCANNER_VERSION=... from the git tag, so releases are correct. But the hardcoded default:

ARG SCANNER_VERSION=0.2.6

means anyone running docker build apps/scanner locally without --build-arg will silently install 0.2.6 even after future bumps. This is an improvement over the old fully-hardcoded pip install line, but the default will drift — slightly undermining the "single source of truth" claim.

---

MINOR-2 — Duplicate importlib.metadata calls
(apps/scanner/src/mpak_scanner/__init__.py, apps/scanner/src/mpak_scanner/scanner.py)

Both files independently call importlib.metadata.version("mpak-scanner") with identical try/except fallback to "0.0.0". They'll always return the same value. scanner.py could simply do:

from mpak_scanner import __version__ as SCANNER_VERSION

instead of duplicating the pattern.

---

NIT-3 — Release step instructions inconsistent between README.md and CLAUDE.md
(apps/scanner/README.md, apps/scanner/CLAUDE.md)

README (steps 3–4) separates "commit and push" from "tag and push" into two distinct steps. CLAUDE.md (step 3) combines commit, tag, and push into a single step. Neither is wrong, but the inconsistency could confuse contributors following one doc vs the other.

[JoeCardoso13]

Solid PR — clean CI/CD pipeline with OIDC trusted publishing, proper version derivation from git tags, and a well-structured multi-stage Dockerfile. Three minor nits below, none blocking.

---

MINOR-1 — Dockerfile ARG default will become stale
(apps/scanner/Dockerfile)

CI always passes --build-arg SCANNER_VERSION=... from the git tag, so releases are correct. But the hardcoded default:

ARG SCANNER_VERSION=0.2.6

means anyone running docker build apps/scanner locally without --build-arg will silently install 0.2.6 even after future bumps. This is an improvement over the old fully-hardcoded pip install line, but the default will drift — slightly undermining the "single source of truth" claim.

---

MINOR-2 — Duplicate importlib.metadata calls
(apps/scanner/src/mpak_scanner/__init__.py, apps/scanner/src/mpak_scanner/scanner.py)

Both files independently call importlib.metadata.version("mpak-scanner") with identical try/except fallback to "0.0.0". They'll always return the same value. scanner.py could simply do:

from mpak_scanner import __version__ as SCANNER_VERSION

instead of duplicating the pattern.

---

NIT-3 — Release step instructions inconsistent between README.md and CLAUDE.md
(apps/scanner/README.md, apps/scanner/CLAUDE.md)

README (steps 3–4) separates "commit and push" from "tag and push" into two distinct steps. CLAUDE.md (step 3) combines commit, tag, and push into a single step. Neither is wrong, but the inconsistency could confuse contributors following one doc vs the other.