Rebuild when the recorded build no longer matches what was asked for

[jgabry]

Rebuild when the recorded build no longer matches what was asked for

Part of the design described in #1254. I asked Claude to write the text below based on that.

---

Supersedes #1019, which predates the build record entirely. Close it when this lands.

Once a record exists (#1238), cmdstan_model() can decide whether the existing executable is still the right one. Today it compares mtimes against the artifact and never compares configuration at all.

The triggers, what identity means for each kind of dependency, and what is left untracked are #1254 §6 ("Contract: when a rebuild happens"). When the assessment runs and what each caller does with the answer is #1254 §5 ("Contract: when validation happens"). Which recorded fields are compared is #1254 §4's table. This issue tracks the work.

Stage 3b: the engine, pure and unwired (#1258)

• The assessment as a pure function of two arguments, expected and observed, never compiling or mutating (Design note: v1.0 compilation state and C++ options #1254 §5, "What the assessment is given"), tested against stage 2's fixtures and called by nothing
• One fixture per trigger in Design note: v1.0 compilation state and C++ options #1254 §6, asserting the reason list and not only the verdict (Design note: v1.0 compilation state and C++ options #1254 §6, "Report every evaluable trigger")
• The fixtures that test an argument rather than a row: a gone builder (no rebuild), a builder mismatch (re-resolution skipped, one reason fewer), the rename pair through stanc_name, and a replaced executable (expected hash differs from observed)
• Stanc option comparison pinned in both directions: list("O1") and list("O1" = TRUE) collapse; a reordered list, and list("O") against list("O1"), rebuild (Design note: v1.0 compilation state and C++ options #1254 §4, "Canonicalization is per-field")

Stage 4: wired in, together with #1256

• cmdstan_model() rebuilds on any trigger, printing every evaluable reason
• Every guarded method errors on a trigger, per Design note: v1.0 compilation state and C++ options #1254 §5's classification table; each exercised with no other arguments so ordering is checked, and the table enforced against the live surface
• Re-resolution runs stanc --info from the recorded builder, with the include paths in force for the call and never the recorded ones (Design note: v1.0 compilation state and C++ options #1254 §6, "Re-resolution uses the include paths supplied on the current call")
• A failed re-resolution is an error carrying stanc's message, at the constructor and at a guarded method; nothing rebuilds (Design note: v1.0 compilation state and C++ options #1254 §5, "A re-resolution that fails is an error, not a verdict")
• Executable-only objects are guarded on the artifact hash alone: replace a recordless executable at the same path and a guarded method refuses; an unchanged one runs (Design note: v1.0 compilation state and C++ options #1254 §7, "A guarded method on an executable-only model checks the artifact hash alone")
• The replaced-executable regression end to end: construct object A, rebuild the same path from B, A's guarded method refuses
• The selected-installation check immediately before make or a tool is invoked out of it (Design note: v1.0 compilation state and C++ options #1254 §6, "A selected installation that is gone is its own error")
• pedantic = TRUE runs the check on an up-to-date model (Design note: v1.0 compilation state and C++ options #1254 §4, "An injection nothing compares still applies")
• edits to included files are not detected #1237 closes with this: the ordered included_files comparison and edits to included files