ci(compliance): hard MB cap on the report tarball so #671 can't recur

[avrabe]

Summary

Scope: Part A of the #671 remediation (additive-only CI defense).

v0.4.x / v0.7-0.9 shipped ~800 MB compliance-report tarballs — a report is HTML + YAML + SVG and should be single-digit MB. The producer has since been fixed (v0.13.0+ is 1-2 MB), but nothing stopped the regression from recurring.

This PR adds a hard max-archive-size-mb cap on the compliance composite action:

• Default 50 MB — legit single-page reports are 1-5 MB, so the cap has ~10-50× headroom without touching multi-page callers who can raise it explicitly. 0 disables.
• Fails the job with a ::error:: line naming Compliance-report packaging bug left ~800MB assets on v0.4.x / v0.7–0.9 releases #671 when the tarball exceeds the cap; the message points at the likely root cause (build output packed into the report directory) so an operator sees the shape immediately, not a bare exit code.
• Emits compliance report size: N MB and a step-summary table on green so a slow creep is visible before it trips the cap.
• Guard logic lives in verify_archive_size.sh (not inline YAML) so it is independently testable.

Test plan

• bash .github/actions/compliance/verify_archive_size_test.sh — 6/6 pass:
  1. 1 MB archive under 50 MB cap → exit 0, size printed, step-summary emitted.
  2. 5 MB archive over 1 MB cap → exit 1, message contains exceeds 1 MB cap, message contains #671, step-summary skipped.
  3. Cap of 0 disables guard even on a 900 MB archive → exit 0 with "size guard disabled" notice.
  4. Missing archive path → exit 2 (usage error).
  5. 2 MB reference-report shape (v0.13.0+ range) sails under the 50 MB default → exit 0.
  6. No args → exit 2 (usage error).
• shellcheck clean on both scripts.
• yamllint clean on action.yml + ci.yml (only pre-existing warnings on unrelated lines).
• Regression test wired into the existing yaml-lint job so a broken guard fails PRs early — no compile cost added.
• Post-merge: next release run's build-compliance step should print compliance report size: 1-2 MB and emit the summary table (real-world verification the AC calls "operational verification").

Acceptance-criteria mapping (Part A, from the #671 triage comment)

AC bullet	How it is satisfied
Producer workflow grows a size gate immediately after the tarball is written; fail if > 50 MB; cap hard-coded in the workflow	New "Verify archive size (#671 regression guard)" step in .github/actions/compliance/action.yml. Default of 50 MB lives on the input.
Failure message prints actual size + threshold ("compliance report is 803 MB, exceeds 50 MB cap")	verify_archive_size.sh emits compliance report is ${SIZE_MB} MB, exceeds ${MAX_MB} MB cap with the ::error:: prefix.
Emit a summary line on green so slow creep is visible	Green path prints compliance report size: N MB and appends a ### Compliance report size table to $GITHUB_STEP_SUMMARY.
Regression coverage: unit test / fixture packs a reference report and asserts < 50 MB	verify_archive_size_test.sh includes a 2 MB reference-shape case and 5 additional edge cases; wired into the yaml-lint job on every PR.
Commit trailers: Trace: skip + Refs: #671	Present on the commit.
Part A explicitly out-of-scope: modification of already-published release assets	This PR only adds CI-side code; no existing artifact is touched.

What's not in this PR

Part B — deleting the 7 stale ~800 MB assets on v0.4.x / v0.7-0.9 release pages — is a public-facing, non-reversible action against tagged releases. Per the triage AC on the issue it needs an explicit "yes, delete these seven assets" comment from @avrabe before a deletion branch opens. Filing that as a separate PR keeps the blast radii separated.

Closes #671 (Part A)

🤖 Generated with Claude Code — issue-triage routine run.

---

Generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!