#9276 fix(ci): reset a broken desktop-live dev cache from a passing job

Summary

• When Turbopack panics on a restored dev cache, desktop-live already empties the cache in its exit trap, but a sticky disk keeps nothing from a job with a failed step, so the clear is discarded and every later run restores the same broken cache and fails the same way
• desktop-live now writes a turbopack-cache-broken marker (the Next version) into its uploaded results when the cache broke
• New desktop-live-cache-reset job runs only after a failed desktop-live, reads the marker, mounts that dev cache and empties it in a passing job, so the empty cache is what the next run mounts
• The key is rebuilt from the run's own event and fork context; the marker only supplies the Next version (validated), so a fork's marker can't name any cache but its own
• A desktop-live failure the cache didn't cause leaves no marker and keeps the warm cache
• Not in ci's needs: it's maintenance, not a gate

Type of Change

• Bug fix

Testing

• actionlint on checks.yml: no new findings (the one finding is pre-existing on staging)
• Ran the key-resolution step locally against good (16.4.0, 16.5.0-canary.3), hostile (path-like, space-injected, empty) and missing markers: rebuilt key matches the live cache key; hostile markers fail without emitting a key
• End-to-end proof is the first staging push after merge: the broken push cache fails desktop-live once, the reset job empties it, and the next run goes green

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing (new tests pass the test-audit authoring gate)
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)