The uv download cache in this action works: it hits exactly (`Cache hit for:
uv-Linux-<hash>`) with one 31 kB straggler still fetched. So what is left in
`Install Unsloth (--local, --no-torch)` is not download, it is compute, and the
elapsed-second prefix added in #9153 says where it goes:

     2s  venv
     5s  overlaying local repo (editable)
    13s  unsloth installed
    16s  node
    20s  bun installed
    58s  frontend built      <- 38s in one phase
    75s  whisper.cpp prebuilt

Measured across 13 distinct Linux jobs on main: the frontend build is a median
36s of a 74s install, 49% of it, and 468s per commit producing byte-identical
output. The spread is 31 to 42s, so it is a deterministic compute cost rather
than variance.

The key, and why it is sound
------------------------------------------------------------------------
studio/setup.sh already decides whether to rebuild, by mtime: it looks for
anything under frontend/ (maxdepth 1, minus bun.lock), frontend/src or
frontend/public NEWER than frontend/dist, and skips the build when it finds
nothing. The cache key hashes exactly those three path groups, so a hit means the
build inputs are byte-identical. That is a strictly stronger statement than the
mtime test it rides on, and it is what makes a restored dist correct by
construction rather than by luck.

bun.lock is IN the key even though the staleness check excludes it. The check has
to exclude it because the install regenerates it and it would self-trigger every
run; the cache has no such problem, and a lockfile change means different
dependencies and so a different bundle. Deliberate, and it makes the cache safer
than the check it rides on.

Three ways this could have looked like it worked
------------------------------------------------------------------------
Each is handled, and each is pinned by tests/studio/test_frontend_dist_cache.py,
because all three are silent.

1. restore-keys. The uv cache above wants them: a near-miss download still
   supplies most of the wheels. A near-miss dist is a bundle built from different
   source, which is wrong rather than partial, so this cache has none.

2. mtimes. actions/cache restores through tar, which preserves the ORIGINAL
   mtimes. A dist restored that way is older than the checkout that just wrote
   every source file, so setup.sh's `find -newer dist` would see the whole tree as
   newer and rebuild anyway: a download paid for, nothing saved, and a cache hit
   reported. One `touch` of the directory is what makes the hit count, and it is
   honest because the key already proved the inputs identical.

3. an empty hashFiles. It returns "" when a glob matches nothing, which collapses
   every commit onto one key and serves an arbitrary dist, with the restore
   succeeding and the build skipped. A step refuses that outright.

The guard
------------------------------------------------------------------------
The failure that matters is not the cache breaking, it is the cache and setup.sh
drifting apart: the key stops covering an input, the cache keeps hitting, and
every job downstream tests a stale bundle that passes. So the guard reads
setup.sh's own staleness block and asserts the key covers the paths found there,
rather than comparing against a list written down in the test.

Mutation-tested, each failing exactly one test: drop src from the key; add
restore-keys; remove the touch; save off main; and add a directory to setup.sh's
check without adding it to the key.

A test I had to change rather than route around
------------------------------------------------------------------------
test_the_cache_holds_uvs_downloads_and_not_the_venv asserted every cache step in
this action points at .uv-cache, and this is the second cache. Its argument is
worth keeping: uv's cache is content-addressed, so a stale entry cannot serve
wrong content, and that property is the whole justification.

A built frontend does not get that argument and needs its own. It is a directory
of static assets with no absolute paths, no interpreter coupling and no console
scripts, which is precisely what makes a venv unsafe to cache and this safe. So
the test now allows exactly two named paths, each with its reasoning recorded at
the list, and keeps the forbidden-install-paths check applying to every cache step
regardless. Verified it still has teeth: pointing the new cache at
~/.unsloth/studio/venv fails it.

Verification
------------------------------------------------------------------------
72 passed across test_uv_cache_discipline, test_frontend_dist_cache,
test_workflow_guards_run_unfiltered and test_cache_budget_discipline.
scripts/lint_workflow_triggers.py: OK across 41 workflow files.
The action still parses; step order is restore, touch, key check, install, save.

Expected effect: about 36s off each of 13 jobs per commit. Cache size is one
built frontend per distinct source state, saved on main only, which is the rule
every other cache here follows.