Coverage Gate + Critical-path Tests

Coverage runs on every API PR through pytest-cov with fail_under=80 and branch coverage enabled. The exclusion list is explicit and conservative — migrations, seeds, __init__.py and TYPE_CHECKING blocks — so the number reflects code that actually executes in production. A coverage.xml artefact uploads on each PR for downstream tooling (the PR comment, dashboards, archival).

The PR gets an automatic comment from py-cov-action/python-coverage-comment-action@v3 with line and branch percentages, deltas versus base and a per-file table. The action is wrapped in continue-on-error=true so a comment posting failure does not block the merge — the gate that matters is the coverage check itself, not the cosmetics. The required check ci-api / coverage refuses to merge anything below 80 %, so the team cannot ship a regression by accident.

The critical-path suite under api/tests/critical_path/ is the second required gate. Seven files cover roughly 55 tests across the flows where a regression has direct cost: signup → subscription → invoice → Stripe charge, license issuance and renewal, GDPR data export, GDPR right-to-erasure, audit-log integrity, capability denial, and payment refund. The suite runs against an in-memory MongoDB via mongomock_motor and a fully mocked Stripe so it is hermetic and fast — full execution measured in seconds, not minutes. The required check ci-api / critical-path blocks merge if any of those flows breaks, regardless of whether the overall coverage number is fine.

Frontend coverage gets a softer treatment because the apps' test surface is shifting fast. admin npm test --coverage runs in CI with continue-on-error=true so a regression flags the PR but does not block, and the coverage artefact uploads with 14-day retention. The intent is to grow toward a hard gate as the suite matures, not to ship one before the team has confidence that the number is stable enough to enforce on every merge.