ci: make ccache effective and observable, shallow checkout, add cache…

[MrLi000001]

… warmer

Measured on the self-hosted runners, the Build step of the same workflow ranges from 2.7 min (warm ccache) to 37.5 min (stale ccache), and a full-history checkout took ~12 min on cache-cold runners.

• Set ccache --max-size=30G (default ~10G is tight for -O3 -g builds) and print ccache -s before/after the build so hit rates are visible in every run log (if: always()).
• fetch-depth: 0 -> 1; CMake only runs 'git log -1' for commit info.
• Add cache_warmer.yml: on every push to develop, build (without tests) on both the X64 and gpu pools so /tmp/ccache stays primed with the latest develop. This prevents the first PR runs after a big refactor merge from all paying a full rebuild.

Reminder

• I have read AGENTS.md and docs/developers_guide/agent_governance.md.
• I have linked an issue or explained why this PR does not need one.
• I have added adequate unit tests and/or case tests, or explained why not.
• I have listed the exact verification commands run and their results.
• I have described user-visible behavior changes, including INPUT parameter changes.
• I have explained core-module impact for ESolver, HSolver, ElecState, Hamilt, Operator, Psi, or other source/ changes.
• I have requested any needed governance exception below.

Linked Issue

Fix #

Unit Tests and/or Case Tests for my changes

• Commands run:
• Result summary:
• Checks not run, with reason:

What's changed?

• Example: brief summary of the user-visible or developer-facing change.

Governance Notes

• INPUT/docs changes:
• Core module impact:
• Exceptions requested:

[Stardust0831]

The shallow checkout and ccache statistics are useful, but I suggest splitting out the cache warmer. It is not yet clear whether /tmp/ccache persists across jobs and nodes in the dynamic runner pool, so one warmer may only warm a single node while consuming an additional GPU. It also builds the default seven CUDA architectures, while #7753 uses sm_70, so those CUDA cache entries will not be effectively reused.

[Critsium-xy]

A few concerns on the cache_warmer.yml half (the test.yml changes look fine to me — I checked that fetch-depth: 1 is safe, since the only git-history consumer is git log -1 in CMakeLists.txt:163-174):

1. The configure flags are copy-pasted and already out of sync. The header comment says to keep them aligned with test.yml / cuda.yml, but as of this commit they already differ: -Werror=dev is missing, and the parallelism is -j8 / -j4 / -j $(nproc) across the three files. A comment can't hold three copies of a build recipe together. Suggest extracting "install toolchain + configure + build" into a workflow_call reusable workflow (or a composite action) that all three call with parameters, so there is one source of truth.

2. /tmp/ccache persistence across the runner pool is unverified. /tmp/ccache is a host path, so if the X64 / gpu pools are multi-node or ephemeral, the warmer only primes whichever node it happens to land on, and every other node still pays the cold build. This is the premise the whole warmer rests on — worth confirming first (e.g. print hostname alongside ccache -s over a few runs and check whether the cache size accumulates on the same host).

3. Neither warmer job sets timeout-minutes. The default is 6 hours. A hung build would hold a self-hosted runner — including a scarce GPU one — for that long and starve PR CI. Please add something like timeout-minutes: 60.

Given 2 and 3, I'd suggest splitting as @Stardust0831 proposed: land the test.yml part now, and bring the warmer back as its own PR once the cache-persistence question is answered.