perf(build): first rebuild after a cold build recompiles once (signature drift between cold and steady state)

[zackees]

Context

With #951 fixed (PR #956), a no-change rebuild of NightDriverStrip demo drops to 2.1 s — but only from the second rebuild onward. The first rebuild after a cold build still recompiles everything once (107 s in the #942 harness):

cold: 780s   hot #1: 107s   hot #2: 2s

The .cmdhash signatures written during the cold build evidently hash a different flag/include assembly than the one the steady-state check computes — most plausibly the include-dir set or its ordering differs while libraries/framework pieces are still being installed mid-cold-build. The first hot rebuild rewrites the stamps under the steady-state assembly, and everything after matches.

Proposal

Instrument the mismatch (log the first differing signature component between write and check for one TU), then make the assembly deterministic — likely stable ordering/normalization of include dirs in CompilerBase::build_include_flags inputs, or computing the written signature from the same assembly the checker will later derive.

Acceptance criteria

• The first no-change rebuild after a cold build is ≤ 10 s in the meta: profiling-driven build performance burndown (Docker Linux, NightDriverStrip, cold vs hot cache) #942 harness (no once-off full recompile).
• Root cause documented (which signature component drifted).
• Before/after harness numbers in the PR description.

Part of #942. Follow-up to #951 / PR #956.

[zackees]

Closing as resolved by #971.

#971 documents the root cause: the stale check compared an object against its own generated depfile mtime, so the first rebuild after a cold build recompiled once even when real prerequisites were unchanged. The fix removed that false-stale comparison while preserving real header/source staleness checks.

Regression coverage added in #971:

• test_depfile_own_mtime_does_not_force_rebuild
• test_depfile_newer_prerequisite_still_forces_rebuild

The separate build_unflags signature asymmetry found during that trace was tracked in #970, which is already closed.

Refs #992.