#30107 ci(nightly): retry local cache after fleet CAS failure

A transient failure in the managed fleet compiler cache currently fails the nightly Release build after the initial CAS probe. This change retries once with Xcode's local cache only when the failed output identifies a compilation-cache or CAS error; unrelated compile failures remain red.

Leo said, “it feels like you guys always forget about incremental builds and the external SSDs.” The retry keeps the warm local/DerivedData path available when the shared cache is temporarily unavailable.

The regression test checks the workflow's runtime retry contract (PIPESTATUS, CAS-specific matching, local retry, and propagation of unrelated failures). Follow-up issue: #30105. The settings-alignment follow-up from the review is tracked in #30106.

Validation:

• python3 tests/test_ci_fleet_compilation_cache.py (7 tests)
• python3 scripts/cmux-next/prepush-gate.py

Review receipt: independent router review of #30061 at beb297ffb5f5a77c7c7f539476c3c9f85df42c84 identified this as a P1 follow-up.

Agent session: agent session
🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Makes the nightly Release build resilient to a transient managed fleet compilation cache outage: when the build fails with a runtime CAS diagnostic, it retries once with Xcode's local cache. Unrelated compile failures stay red.

• The retry triggers only on compiler runtime cache failures (for example, "CAS error encountered during compilation", "CAS error: No such file or directory", "remote service unavailable"), not on source errors that merely mention CAS or cache.
• Adds a stricter cmux_next_runtime_cas_failed predicate and regression tests covering the retry contract (PIPESTATUS, local retry, unrelated failure propagation).