ci: setup-bun cache key differs between restore and save, exact cache hits never happen

Summary

The setup-bun composite action (.github/actions/setup-bun/action.yml) never gets an exact cache hit on dev. Restore and save both use hashFiles('**/bun.lock'), but they run at different times: restore before bun install, save after. Once node_modules exists, the glob also matches lockfiles shipped inside dependencies, so the two keys differ. The key that gets saved is never the key that gets looked up.

Evidence

Last three test.yml runs on dev (34011772829, 34011717028, 33998805878), unit (linux) job:

Cache hit for restore-key: Linux-bun-bdcce106…      <- fallback prefix match, not the primary key
Failed to save: Unable to reserve cache with key Linux-bun-b26debf2…

Reproducing hashFiles locally on a fresh clone of dev (sha256 of each file's sha256, sorted by path):

The save hash matches the CI log exactly. The restore hash is never saved by anyone.

Effect

Dependencies are always restored from whatever Linux-bun-* entry is newest, regardless of lockfile, and then re-saved under an unreachable key on every push. It still works thanks to restore-keys, so the failure is silent, but exact hits never happen and the cache is not invalidated by lockfile changes.

Fix

Compute the key once, before bun install, and pass it to both actions/cache/restore and actions/cache/save. PR incoming.