Speed up CI with build caching and parallel jobs

[wasphin]

What problem does this PR solve?

Issue Number: resolve

Problem Summary:
CI recompiles the same sources, downloads the same Bazel dependencies, and
runs the Make and CMake configurations serially on every run, making build
validation unnecessarily slow.

What is changed and the side effects?

Changed:

• Add a shared composite action that configures ccache for Make/CMake builds.
• Cache Bazel repository downloads separately from Bazel build outputs.
• Reuse caches in Linux and macOS build jobs.
• Report ccache statistics so cache behavior can be verified from CI logs.
• Run the four Linux CMake compiler/configuration combinations as independent
  matrix jobs.
• Run the four Linux Make compiler/configuration combinations as independent
  matrix jobs.
• Run the GCC and Clang Protobuf compatibility builds as independent matrix
  jobs.
• Consolidate each Linux job's APT dependencies into one update/install
  transaction.
• Upgrade checkout to the Node.js 24-based action release.
• Give each ccache job/configuration an unambiguous namespace so restore
  prefixes cannot select another job's cache.
• Disable Bazel test-result caching so every CI run executes all tests while
  still reusing cached compilation actions.

Measured results:

• The latest successful Linux run reduced the slowest job from a 38:25
  baseline average to 21:43 (43.4%). Total runner time across the measured
  Linux jobs fell from 270:09 to 143:45 (46.8%).
• The Make and CMake matrix critical paths were 4:45 and 4:06, compared with
  serial baseline averages of 16:09 and 18:38. Their total runner times were
  15:30 and 14:37, respectively.
• GCC and Clang Make/Protobuf matrix critical paths were 1:59 and 2:11,
  compared with serial baseline averages of 19:32 and 20:39.
• With Bazel test-result caching disabled, the three Bazel unit-test jobs took
  16:36-20:22, reductions of 35.0%-49.8% from their baseline averages. Every
  test still executed; only downloads and compilation actions were reused.
• The latest successful macOS run reduced total runner time from a 28:28
  baseline average to 9:47 (65.6%).

The baseline is the average of 10 successful runs. The post-change values are
from the latest successful run, so they represent the current configuration
rather than a multi-run post-change average.

Side effects:

• Performance effects: Subsequent CI runs can reuse compiler outputs and Bazel
  downloads/build outputs. Ccache is bounded to 2 GiB. Bazel repository caches
  are shared per platform, while build caches remain separated by job. Bazel
  tests always execute; only their compilation actions remain cacheable.

• Breaking backward compatibility: None.

---

Check List:

• Please make sure your changes are compilable.
• When providing us with a new feature, it is best to add related tests.
• Please follow Contributor Covenant Code of Conduct.