[kvlonge]

Why

Analysis preparation called native SQL normalisation once per model or shared binding query from Python. Most of that time was threads waiting to reacquire the GIL after each short call: about 1.6 s at dense 3k and 5.4 s at dense 10k cold (CHI-509).

Changes

• The three normalisation points in analysis preparation now make one native call per chunk of 256 models with the GIL released. Each model keeps its own result or error in place, and Python raises errors at the same point and with the same message as before.
• Chunks run in parallel on the compile's existing analysis pool when no analysis batch is running on it, otherwise sequentially in the same call, so preparing the next batch never waits behind a running one.

Verification

• Quiet host, alternating, medians: analysis preparation at dense 3k cold 1597 → 834 ms (wall 17.35 → 16.54 s), dense 10k cold 5436 → 2947 ms (wall 53.2 → 51.9 s); warm-miss also faster; edits and a ~1,400-model project unchanged; peak memory within noise.
• Oracle comparing per-model and batched preparation (payloads, cache keys, cache hits, compile output) on fixtures, random projects with errors and dense 120/3k; fails when a batched result is perturbed. Rust tests for ordered results and errors.
• One independent review; make test, make check-ci.