fix(ci): make fmt resilient to server_timeout_running on flaky runners

Two changes:
1. Use CARGO_HOME=/root/.cargo + before_script:[] + cache:[] for fmt.
   cargo fmt --check does not compile and needs no registry download.
   GitLab CI cache downloads happen before any log output — if the download
   hangs on a flaky runner, the job silently times out with server_timeout_running
   and an empty trace, blocking all downstream jobs.

2. Switch retry when: to `always`. GitLab has no retry keyword for
   server_timeout_running (internal code). `always` ensures infrastructure
   failures (container-start, cache-download, runner crash) are retried on
   a different runner. Real format violations fail deterministically on all
   retries and still produce a correct FAIL outcome; max: 2 caps wasted runs.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.gitlab-ci.yml

@@ -62,16 +62,21 @@ default:
 
 fmt:
   stage: quick-checks
-  # Explicit timeout so a stuck runner hits job_execution_timeout (retryable)
+  # Use pre-baked /root/.cargo from the Docker image so there is no GitLab CI
-  # instead of GitLab's 60m server_timeout_running (not matched by any retry keyword).
+  # cache download before the script. Cache downloads happen before any log
+  # output and can silently hang on flaky runners, producing server_timeout_running.
+  # cargo fmt --check does not compile — it only needs rustfmt, not the registry.
+  variables:
+    CARGO_HOME: /root/.cargo
+  before_script: []
+  cache: []
   timeout: 10m
+  # server_timeout_running is not matched by any GitLab retry keyword; use
+  # `always` so infrastructure failures retry on a different runner. A real
+  # format violation is deterministic and fails all retries — max: 2 limits waste.
   retry:
     max: 2
-    when:
+    when: always
-      - stuck_or_timeout_failure
-      - runner_system_failure
-      - unknown_failure
-      - job_execution_timeout
   script:
     - cargo fmt --all -- --check