cc_gate: cache each spec's C-header result by content -- 72 s of every t27c suite run (needs cc_gate.rs on the exception list) #8900

Part of #8737 (hot reload), epic #8095. Split out of #8829, where it was "not here".

Problem

• Where the time goes: the C-header gate, cc_gate::run, called from "Integrity metrics" in t27c suite and by t27c cc-gate, takes 72 s alone on this Mac (load ~10). It is the largest cost left in a suite run, ~72 of ~170 s locally, and the same in CI's corpus ratchet.
• Why: for every spec it regenerates the C header (use_resolve::resolve, then Compiler::compile_c) and runs cc -fsyntax-only on it, one spec after another, on every run, although almost no spec changed since the last run.

Proposed change

• A spec, e.g. specs/verified/cc_gate_cache.t27, decides when a cached result may stand.
• The key:
  • the resolved spec text and the raw spec text (compile_c falls back to the raw text);
  • the t27c binary's digest, through the stat-keyed digest cache of silicon: a bitstream reuse hit takes tool digests from a stat-keyed cache, 4.3-8.9 s -> 1.5-2.6 s (Closes #8805) #8808;
  • the C compiler's path and --version.
• What is cached: OK, the first error line of a FAIL, or "no header generated".
• What is never cached: a spawn or write failure.
• Optionally, the per-spec loop could run through par_in_order, as the other suite phases do since t27c suite runs its read-only per-spec subprocess phases in parallel -- those phases 269 s -> 71 s, the suite 498 s -> 276 s (Closes #8829) #8837.

Why this waits for the owner

bootstrap/src/cc_gate.rs is not on tools/policy/foreign-exceptions.txt, which is owner-only. Until it is, the only-t27 gate refuses any edit to it.

Acceptance criteria

• With a warm cache, t27c cc-gate prints the same report (counts, classes, failures in the same order) and takes under 5 s.
• After an edit to one spec, only that spec's header is generated and compiled again.

Boundary

bootstrap/src/cc_gate.rs

User Scenarios

• Given a warm cache from a previous t27c suite run, When I run t27c cc-gate again without changing any specs, Then the command prints the identical report (counts, classes, failures in the same order) and completes in under 5 seconds.
• Given a warm cache, When I edit exactly one spec file and run t27c cc-gate, Then only that spec's C header is regenerated and syntax-checked; all other specs use cached results.

Requirements

FR-001: The cc_gate cache key MUST include the resolved spec text, the raw spec text, the t27c binary digest (via the stat-keyed digest cache), and the C compiler path with its --version output.
FR-002: The cache MUST store only successful results (OK), the first error line of a FAIL, or the "no header generated" state.
FR-003: The cache MUST never store results from spawn failures or write failures.
FR-004: The per-spec loop in cc_gate::run MAY use par_in_order to process specs in parallel while preserving report order.
FR-005: A spec file specs/verified/cc_gate_cache.t27 MUST define when a cached result may be reused.
FR-006: The file bootstrap/src/cc_gate.rs MUST be added to tools/policy/foreign-exceptions.txt to allow edits by the only-t27 gate.