feat(querygen): add realization-batch checkpoint artifact

[henrycgbaker]

Stack (6 open PRs): #236 → #237 → #238 → #239 → #240 → #241 → #242

Chain goal: Add per-batch checkpoint/resume to querygen so a re-run with the same run_id skips already-completed work. Nests resumable state under <run_dir>/checkpoints/, writes a frozen Stage 1 result (planning + dedup) plus per-batch Stage 1 and Stage 2 artifacts, and orchestrates resume behind a fail-fast config-drift gate (--force overrides) so checkpoints are never silently reused under changed settings.

This PR (5/6): Third and final vertical artifact slice. Adds per-batch checkpointing for Stage 2 realization. Stage 2 batches are independent (no chained state), so each batch resumes on its own merits — the candidate_ids header field binds each checkpoint to its exact frozen-result chunk.

---

What

• RealizationBatchArtifact schema with extra="forbid" + 1:1 candidate_ids/queries model_validator.
• assemble_realization_batch_artifact + export_realization_batch_artifact (atomic).
• read_realization_batch_artifact — thin typed wrapper over the feat(querygen): add planning-batch checkpoint artifact and read engine #239 engine.

Why

Stage 2 has no chained state between batches, so each realization batch is checkpointed independently — a rerun replays only the batches that didn't complete. Binding the checkpoint to its candidate_ids chunk means a re-chunked frozen result can't silently reuse a stale realization.

Test plan

• tests/unit/core/querygen/test_realization_batches.py — round-trip, header-mismatch per field, version-mismatch, malformed JSON, length-validator.

[saschagobel]

The realization-batch artifact boundary makes sense to me for crash recovery. Since Stage 2 batches do not carry chained state, checkpointing them independently is a good fit, and binding each artifact to its candidate_ids chunk is the right safeguard against accidentally applying a checkpoint to the wrong blueprint slice.

My concern is mainly with how this fits into the wider stack. I would avoid carrying the per-stage reuse model into this artifact contract. For v1, realization checkpoints should be validated against the same strict same-run/same-effective-settings compatibility model as the rest of the checkpoints. If settings that affect the run differ, I’d rather fail clearly and ask the user to start a new run or delete/recreate the existing one, rather than enabling partial reuse/recompute semantics through stage-specific drift handling.