On startup the initial `cargo check` flycheck was launched in the same `became_quiescent` block as cache priming, so the two ran concurrently and fought for CPU. Neither is single-threaded: cache priming fans crate work across worker threads and `cargo check` spawns up to one rustc job per core, so running them together oversubscribes the cores. The effect is felt particularly on macOS, where rust-analyzer's priming threads run at `QOS_CLASS_UTILITY` (`ThreadIntent::Worker`) while the `cargo check` subprocess runs at the default, higher QoS -- so the scheduler starves priming (the work that makes the editor usable) in favour of the check. Move the initial workspace flycheck out of `became_quiescent` into the `PrimeCachesProgress::End` handler via a `pending_initial_flycheck` flag, so the check only starts once priming has finished; fall back to firing it immediately when cache priming is disabled. The flycheck still runs (cargo check begins right after indexing); diagnostics are deferred a beat, not lost. The impact depends on how much the startup `cargo check` has to compile: - Warm check (steady-state reopen): contention is negligible, so this is effectively neutral -- and harmless, deferring a fast check costs nothing. - Cold check (first open after clone / `git pull` / branch switch / toolchain change, where startup already hurts): large. Time-to-ready (cache priming complete) measured on macOS with a cold check, build scripts and proc-macros disabled to isolate the priming/check contention: rust-analyzer 74.8s -> 7.9s (~9.5x) slint 103.1s -> 26.6s (~3.9x) Flycheck slow-tests pass. Disclosure: prototyped with assistance from Claude (Anthropic); changes reviewed and owned by the committer.