ci: evict majestic's moving S3 tarball from the dl cache too (#109)

PR #105 added a "Refresh moving-ref package downloads" step that drops
*-{HEAD,master,main,dist}.tar.gz before each build so buildroot re-fetches
the current ref. That fixed the majestic-webui-dist.tar.gz staleness (the
*-dist.tar.gz case), but it never matched majestic itself.

majestic downloads from S3 as majestic.<family>.<variant>.master.tar.bz2
(majestic.mk) — a DOT separator, .tar.bz2, and an S3 host the old pattern
deliberately spared as "content-addressed". But that S3 object is a moving
`master` build, re-uploaded on every majestic CI run, with no .hash to force
a refetch. So it stayed frozen in the monthly builder-dl cache while the
webui refreshed — the exact desync that shipped a pre-x-groups majestic in a
t31 lite image against the current webui, blanking the settings page with
"No settings groups in schema."

Broaden the eviction to a regex covering both -ref and .ref separators across
gz/bz2/xz, so majestic.*.master.tar.bz2 and majestic-webui-dist.tar.gz are
both dropped while semver/SHA-pinned tarballs keep their cache.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.github/workflows/master.yml

@@ -226,17 +226,20 @@ jobs:
         run: |
           # builder caches BR2_DL_DIR (/tmp/builder-dl) under a monthly key
           # (date +%m) and actions/cache only saves on a key miss, so the first build
-          # of the month freezes it for weeks. Packages pinned to a moving ref
-          # (VERSION = HEAD / branch, or the majestic-webui `dist` release asset)
-          # download as a constant <pkg>-<ref>.tar.gz, so buildroot keeps reusing the
-          # stale tarball — even though builder re-clones firmware HEAD each run for
-          # freshness. (Empirically: a 06-14 builder nightly shipped a ~2-week-old
-          # majestic-webui — full bootstrap.min.css, no mj-settings.js — while the
-          # firmware nightly shipped the current UI.) Drop those archives so buildroot
-          # re-fetches the current ref each run. Content-addressed packages
-          # (S3 / semver / SHA pins) keep their cache.
-          find /tmp/builder-dl -type f \
-            \( -name '*-HEAD.tar.gz' -o -name '*-master.tar.gz' -o -name '*-main.tar.gz' -o -name '*-dist.tar.gz' \) \
+          # of the month freezes it for weeks. Packages pinned to a moving ref keep a
+          # constant download filename, so buildroot reuses the stale tarball — even
+          # though builder re-clones firmware HEAD each run for freshness. Two forms:
+          #   - dash:  <pkg>-<ref>.tar.gz   e.g. majestic-webui-dist.tar.gz
+          #   - dot:   <pkg>.<ref>.tar.bz2  e.g. majestic.t31.lite.master.tar.bz2
+          # The dot form is majestic's S3 tarball: it LOOKS S3-pinned but is a moving
+          # `master` build re-uploaded every majestic CI run, with no .hash to force a
+          # refetch — so it must be evicted too. (Empirically: a 06-14 nightly shipped a
+          # ~2-week-old majestic-webui; later a t31 lite image shipped a pre-x-groups
+          # majestic against the current webui — "No settings groups in schema".) Drop
+          # both forms so buildroot re-fetches the current ref. Only genuinely
+          # content-addressed tarballs (semver / SHA in the name) keep their cache.
+          find /tmp/builder-dl -type f -regextype posix-extended \
+            -regex '.*[-.](HEAD|master|main|dist)\.tar\.(gz|bz2|xz)' \
             -print -delete 2>/dev/null || true
 
       - name: Build firmware