docs/ci: say to measure the GC window before relying on the stagger

The guidance says to stagger two hosts' collections, and never says how
long one takes — so an operator picking `dates` has no way to know
whether their stagger is wide enough.

The number that matters is theirs, not mine: a collection's wall clock
is dominated by the sweep over unused `.links` entries, which scales
with the size of the store rather than with what the run deletes. So a
store's size, not its churn, decides the window, and `randomizedDelaySec`
spreads only the start.

Measured here for scale, and deliberately kept out of the doc since it
does not transfer: 11 runs over two weeks ranged 5min 16s to 51min 25s,
inversely — the 51-minute run deleted 732 paths, a 12-minute run deleted
21,901.

Refs #4019.

docs/scheduler/ci.md

@@ -234,6 +234,13 @@ following to your host config:
 }
 ```
 
+**Measure a collection on your own hosts before relying on that stagger.**
+`randomizedDelaySec` spreads the _start_, not the run, and the run is dominated
+by the sweep over unused `.links` entries — which scales with the size of the
+store, not with what this collection deletes. On a large store it can take most
+of an hour, so two hosts both set to `daily` may overlap however much jitter you
+give them. `journalctl -u nix-gc.service` reports each run's wall clock.
+
 **Remote builders:** if CI dispatches builds to a remote builder (for example via
 `nix.buildMachines` / `ssh-ng://`), the build outputs land in _that host's_
 store, so the same GC config should be applied wherever the builder runs —