[CI] Keep the measured ccache bounds instead of raising them

Steady-state master shows Arch at 90.1% and Debian 13 at 96.75% per-run
hits on the existing 850M/800M bounds. The 75%/82% that motivated the
increase were warming runs right after the -g1 switch invalidated the
cache, not thrashing. Keep the bounds, keep the macOS 14 cache drop.

.github/workflows/desktop-build.yml

@@ -150,7 +150,7 @@ jobs:
             allow-failure: yes
             package: skip    # We are packaged in Arch already
             debug_test: yes    # see the note on Fedora 45 below
-            ccache_size: 1200M    # Debug plus the suite: 680 MB working set at -g1; 850M thrashed
+            ccache_size: 850M    # Debug plus the suite: 680 MB working set at -g1
 
           - distro: Servatrice_Debian
             version: 12
@@ -165,7 +165,7 @@ jobs:
             version: 13
 
             package: DEB
-            ccache_size: 1050M    # Release plus the suite: 625 MB working set at -g1; 800M thrashed
+            ccache_size: 800M    # Release plus the suite: 625 MB working set at -g1
 
           # The single Fedora leg used to build Debug for the suite and Release for the
           # package in one job (measured on Fedora 44: 30.8 min, the only leg slower than
@@ -225,33 +225,34 @@ jobs:
       # whole configuration therefore buys almost nothing, and the quota goes to fewer legs
       # at a size that holds one:
       #
-      #   Arch                 Debug + suite       680 MB working set   1200M
-      #   Debian 13            Release + suite     625 MB               1050M
+      #   Arch                 Debug + suite       680 MB working set   850M
+      #   Debian 13            Release + suite     625 MB               800M
       #   Fedora 45 debug      Debug + suite       660 MB               850M
       #   Fedora 45 release    Release + package   614 MB               800M
       #
-      # That is about 3.9 GB of bounds, and with the fixed entries above (about 4.4 GB) it
-      # puts the quota at roughly 8.3 GB of 10 - so only legs worth their share get one. A
-      # leg keeps no cache when it duplicates another leg's coverage (Ubuntu 26.04 behind
-      # Debian 13's Release + suite; macOS 15 and macOS 27 Debug behind macOS 14) or
-      # finishes well inside the Windows leg (Servatrice covers the server alone in 4.7
-      # min). All three macOS legs run cold: macOS 14's 800M cache served 42% and saved
-      # about 32s on a 20 min leg that is already shorter than Windows, so that bound is
-      # better spent here. The four Linux legs that stay compile the client on the
-      # toolchains a change can break and are the ones a cache shortens by the most.
+      # That is 3.3 GB of bounds, and with the fixed entries above (about 4.4 GB) it puts
+      # the quota at roughly 7.7 GB of 10 - so only legs worth their share get one. A leg
+      # keeps no cache when it duplicates another leg's coverage (Ubuntu 26.04 behind
+      # Debian 13's Release + suite; the macOS legs behind the Linux ones) or finishes well
+      # inside the Windows leg (Servatrice covers the server alone in 4.7 min). A macOS
+      # cache served 42% and saved about 32s on a 20 min leg that is already shorter than
+      # Windows, so that bound is better spent here. The four Linux legs that stay compile
+      # the client on the toolchains a change can break and are the ones a cache shortens
+      # by the most.
       # Measured job totals on master 2026-11-04 also show the ceiling this leaves:
       # Windows 10 is 29.5 min and compiles for 23.7 of it with no compiler cache at all, so
       # Windows still sets the pull-request wall clock no matter how warm these legs are
       # (see build-vcpkg).
       #
-      # Measured on master 2026-11-06: Fedora 45 debug/release hit 99.5% at 80% full, while
-      # Arch served 75% at 96% full and Debian 13 82% at 96% - both evict entries they need.
-      # A cold 3G run on 2026-11-07 measured one configuration at 680 MB (Arch) and 625 MB
-      # (Debian 13), so the old 850M/800M bounds already exceeded the working set. They
-      # thrashed because commit-to-commit churn filled the ~170 MB of slack and evicted live
-      # entries. The bounds above leave 520/425 MB for that churn, so the working set stays
-      # resident across compiler and image updates. The sanitize leg's 1.2G cache is
-      # nightly-only now, and macOS 14's 800M is dropped; that is what funds the increase.
+      # Steady-state master data corrected this on 2026-11-07: Arch 90.1% and Debian 13
+      # 96.75% per-run hits at the 850M/800M bounds, Fedora 45 debug 99.18% and release
+      # 99.2%. The 75%/82% seen the day before were warming runs - the -g1 switch had
+      # invalidated the cache one commit earlier - not thrashing at the bound. A cold 3G
+      # run on the same day measured one configuration at 680 MB (Arch) and 625 MB
+      # (Debian 13), so those bounds already hold the working set with ~170 MB of slack for
+      # commit-to-commit churn, and raising them buys hit rate the numbers do not show a
+      # need for. macOS 14's 800M entry is dropped because persistence buys 32s there; the
+      # quota stays free for the legs whose bounds would actually miss.
       #
       # Re-add a leg only with a bound that holds its whole configuration: a smaller one is
       # worse than none.