[kvlonge]

Why

Compiles start a speculative SQL lint in a background thread. When the compile has graph errors, the rules step never runs, but the compile still blocked for the lint to finish, about 10 s on a ~1,400-model project, outside every timing phase. The thread also competed for the GIL with model analysis. The lint itself rebuilt each file's newline table once per violation, character by character (CHI-479).

Changes

• Build each file's newline table once per lint pass.
• The early lint checks a stop flag between files and bodies. The compile stops it right after the graph phase when there are graph errors, and otherwise after rules, so a result that is consumed is never cut short.
• New compile_timings.early_lint_wait_ms records any remaining wait.

Verification

• Same-machine medians (CPU s, base 0.132.1 → head): ~1,400-model project with compile errors, cold 33.1 → 22.3, warm 24.2 → 13.5. Dense 3k with lint findings, cold 50.9 → 47.2 (built-in rules 25.3 → 15.9 s). Diagnostics and rule findings identical.
• Unit tests for locations; integration test that the lint is stopped, not awaited, on graph errors; DuckDB E2E for error and clean projects (findings identical).
• One independent review; make test, make check-ci.