[kvlonge]

Why

On warm compiles, compiler-integrated SQL Rules still lint files that cannot be cached (for example SQL tests or audits that call macros). That lint path rebuilt the whole SQL expansion context: it re-executed every macro module, rebuilt and revalidated the declaration scope, and re-read every project SQL file even though the compile had just done all of this.

Changes

• CompileProjectInputs keeps the compiler's DeclarationScopeBuild. Post-assembly SQL Rules lint reuses it when the discovery inputs are the same object, instead of rebuilding macros and scope.
• run_lint / collect_project_files accept file contents already read by the Rules pass, with the same selection filter.
• The background early-lint thread still builds private macro instances, because project assembly can still invoke macros while it runs (found in review).
• SQL-test comment matching returns early when no pattern occurs in the SQL.
• New integration test: a warm compile with a folder-scoped macro in test SQL builds the declaration scope exactly once and reports the same findings as the cold compile. It fails on main (two builds).

Verification

• Paired alternating warm and cold compiles on a large real project: compile JSON and every compiled artifact byte-identical. Warm compile a few percent faster, cold neutral, memory unchanged.
• Focused Rules, lint and compile integration suites pass. make test passes (3 pre-existing failures came from a stale local native build and pass after rebuilding).
• make check-ci green. One read-only review; its single concurrency finding is fixed.