fix(ci): resolve Trivy HIGH CVEs blocking Tier 2 Governance on main

[paruff]

Summary

Tier 2 Governance's Trivy scan has been failing on every push to main (predates #376 — the same two CVEs failed the prior push too) on two HIGH CVEs that trace back to pip itself, not the app's real dependencies:

• msgpack 1.1.2 (GHSA-6v7p-g79w-8964) — pip's own vendored copy at pip/_vendor/msgpack, not our installed msgpack (already resolves to a clean version transitively).
• setuptools 70.3.0 (CVE-2025-47273) — not installed anywhere; it's a version string in pip's _vendor/vendor.txt manifest that Trivy's scanner parses as an "installed" package.

pip is never invoked at container runtime (entrypoint.sh only runs manage.py/gunicorn), so this strips it from the final image after the existing setuptools/wheel CVE-patch step. Also removes the now-pointless ensurepip bundled wheel (same class of issue), and pins msgpack==1.2.1 directly since it's also a real (if separate) transitive dependency via pytest-bdd→gherkin-official.

Changes

• Dockerfile: drop ensurepip bundled wheels in the base stage; remove pip from the runtime stage after the setuptools/wheel upgrade.
• requirements.txt: pin msgpack==1.2.1.

Test plan

• Rebuilt the image locally with the fix
• trivy image --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 → exit code 0 (clean)
• Confirmed msgpack resolves to 1.2.1 and setuptools to 83.0.0 inside the built image
• Confirmed ensurepip/_bundled is empty and pip/pip3 are gone from the image
• Booted Django inside the built image (django.setup()) to confirm removing pip doesn't break the app
• CI Tier 2 Governance run on this PR (will confirm green)

🤖 Generated with Claude Code