chore(analytics): update release churn statistics

[github-actions]

Automated update of release-over-release update churn, layer reuse efficiency, and zstd compression statistics triggered by updated SBOMs and OCI manifests. Requires maintainer approval before merge per repository policy.

[hanthor]

This PR is already stale, and no CI ran on it at all

1. Zero checks executed

pull_request_read(method="get_check_runs", pullNumber=1216)
→ {"total_count":0,"check_runs":[]}

Every other open PR in this repo has at least the Build Docusaurus job. This one has none — it was opened by github-actions[bot] using the default GITHUB_TOKEN, which by design does not trigger further workflow runs. mergeable_state is unstable as a result. Nothing has validated this payload.

2. The data is a day old and only the dates changed

$ git diff origin/main pr1216 -- static/data/update-churn.json
-  "generatedAt": "2026-09-10T05:16:04.080Z",
+  "generatedAt": "2026-09-11T05:15:51.183Z",
...
-          "date": "2026-09-10",
+          "date": "2026-09-11",
   (x3, one per image)

That is the entire diff: 4 added lines, 4 removed. Every downloadChurnMB, sharedMB, and compression figure is byte-identical to main. The PR moves timestamps forward and changes no statistic.

Today is 2026-09-12, so the generatedAt this would commit is already 24h behind, and .github/workflows/update-churn-cache.yml regenerates on cron: "0 5 * * *" daily:

  schedule:
    - cron: "0 5 * * *" # 05:00 UTC daily (1 hour after 04:00 UTC nightly SBOM update)

Each run opens a fresh chore/update-churn-YYYYMMDD branch (git log shows #1180 for 20260910, #1149 before that). So this branch is superseded by construction: merging it lands yesterday's timestamp, and tomorrow's run supersedes it again.

Recommendation

Close this and let the next scheduled run open a current PR, or re-run update-churn-cache.yml via workflow_dispatch so the branch carries today's data. Merging as-is commits a stale generatedAt that the very next cron tick overwrites.

Separately, worth fixing at the workflow level: the churn PRs get no CI because of the GITHUB_TOKEN restriction. Either have the workflow use an app token / PAT so pages.yml runs, or add a workflow_run-style validation, otherwise this file is committed to main unvalidated every single day.

---

Generated by Claude Code