[kvlonge]

Why

The UI's model page shows microbatch coverage: what is complete, where the holes are, and what a version change still needs rebuilt. That history is mirrored from the warehouse but was never projected.

Changes

• GET /api/control/locations/{location}/targets/{target}/microbatches/{model}?limit= returns coverage of the model's newest recorded relation and generation, or null. Only concurrent microbatch models are tracked. Needs view on the whole target.
• Uses the executor's native coverage projection. Batches are:
  • complete;
  • gap, a hole between completed partitions;
  • replay_required, inside the newest live replay requirement and completed at another version. A newer completion at a third version ends it, as in the executor.
• Adjacent pieces of one completion merge; zero-width pieces are dropped. Each batch keeps its completion's own bound text.
• known_gaps lists every hole; batches holds the newest limit (default 200, cap 1000).
• Bounds sort by value: integers, and timestamps via the existing CPython fromisoformat port, so +00 offsets work and instants order correctly.
• sqlbuild-model-config (depends only on sqlbuild-core) moves one layer earlier so the control server can use that parser.
• New index on the model. Earlier pre-release control stores are refused and must be recreated.
• Client regenerated.

Verification

• cargo test -p sqlbuild-orchestration --all-features: 102 passed on SQLite and PostgreSQL. The endpoint test covers integer and offset bounds whose text order is wrong, mixed bound spellings, a newer overlapping completion, two requirements, a superseded one, both hole kinds, other scopes, generations and models, truncation, an untracked model and a denial. Mutating each rule fails it, except dropping the zero-width skip, which the merge absorbs.
• make check-ci, public-repository scan.
• One read-only review; its two blockers are fixed and rechecked.
• DuckShop: microbatch_coverage.json.