[kvlonge]

Why

Model attachment (macro expansion, header columns, config, visible declarations, validation) ran for every model on every compile, about 25% of warm compile time (CHI-442, part of CHI-441).

Changes

• Each model's attachment result is cached in the compile cache. The key covers the model file, applicable defaults and path defaults, vars, target (including target-level env values), adapter and dialect, the visible macro and declaration set, hook and audit-factory sources, custom adapter files under adapters/, and the installed code and native build identity.
• Models whose own config, hooks or SQL read an environment variable or run.id are rebuilt every run.
• Attachment diagnostics are stored and replayed on a hit; reference-name checks re-run on every hit, so adding a model only rebuilds that model. A macro or declaration edit rebuilds all models.
• Docs: macros must be deterministic, and the docs say exactly what the reuse check covers.
• Dense warm/edit guards assert attachment hit counts.

Verification

• Same-machine medians, CPU s (base → head): dense 3k warm 10.70 → 9.90 and one-edit 12.58 → 11.78; 5k one-edit 19.85 → 18.72; ~1,400-model project warm 23.36 → 21.50. Output identical.
• Invalidation E2E per input kind against --no-cache, each mutation-checked; run.id, env, diagnostic replay, model add/remove and macro edits.
• One independent review plus a follow-up; make test, make check-ci.

[kvlonge]

Shelving this PR. After #919 (speculative lint stop) and #922 (cold-compile GC pause) landed, the gain shrank to about 1–2% on the dense benchmarks and about 0.6 s on a ~1,400-model project, while cold compiles got ~1.7% slower and the fresh-process cache guard passes only narrowly. Most of the attachment time in the original profile came from GIL contention with the speculative lint, and unpickling cached attachment facts costs nearly as much as recomputing them. The branch stays available if attachment becomes a bottleneck again.