Harden derived coverage, restore generations, and full CI gates

[ajroetker]

Summary

• implement durable derived coverage accounting with explicit skipped outcomes, generation-scoped counters, restore repair, and runtime status
• stage, validate, sync, and atomically publish restored DB generations while retaining DB, transaction, and cursor ownership through generation transitions
• make table and cluster restore a durable asynchronous job control plane with replicated persistence, FIFO recovery, attempt fencing, cancellation, and bounded progress state
• scope idempotency by authenticated principal and restore target, expose opaque string job IDs, and omit terminal-only expiry from active jobs
• preserve named external-I/O authority while forwarding cluster backup work from metadata leaders to data owners
• prevent stale runtime observations and startup catch-up completions from regressing newer index status or durable projection checkpoints
• define the production dense-index lifecycle for streaming replay, isolated bulk publication, shadow repair generations, replay pins, resource admission, and readiness states
• align generated Go, Python, TypeScript, and Zig SDK contracts and harden backup/restore E2E assertions around the durable job model

Closes #308.
Closes #350.

Production Invariants

• one cached read owner and one cached write owner per table shard generation
• restore requires an exclusive generation capability and publishes only a closed, validated sibling generation
• retired generations remain alive until their transactions, cursors, workers, and cache leases drain
• restore jobs survive process and metadata-leader changes; recovered running attempts are fenced and resume in durable FIFO order
• explicit idempotency keys are scoped to principal plus table/cluster target; requests without a key always create independent jobs
• cluster progress uses compact inclusive ordinal ranges, remains bounded under maximally fragmented completion, and cannot mark a table complete before publication
• explicit restore requests are limited to 256 tables; all-table cluster operations are admitted atomically up to 4096 tables
• terminal cluster results expose bounded aggregate counts and at most eight bounded failure details instead of retaining unbounded per-table payloads
• distributed backup forwarding carries the validated connection name end to end; an owner never bypasses the caller's external-I/O authority
• runtime status prefers topology generation, visible LSM root, and same-producer report generation before source/freshness timestamps
• durable projection checkpoints are the lower bound for reported replay progress
• ordinary dense replay leaves each committed batch structurally reopenable; incomplete bulk publication is reserved for isolated import/rebuild generations

API Behavior

• POST /db/v1/tables/{table}/restore and POST /db/v1/restore return 202 RestoreJob only after durable job admission succeeds
• job_id is an opaque decimal string; clients poll the Location resource and must not parse the identifier as a number
• expires_at_ms is omitted for queued/running jobs and appears only once a terminal record enters retention
• terminal cluster results report committed, triggered, skipped, and failed counts plus bounded failure details
• Idempotency-Key safely retries the same scoped restore request and returns 409 when reused with a different request fingerprint
• table and cluster backup/restore require a named external_io connection, including metadata-leader-to-data-owner forwarding
• restore publication checkpoints make retries and leader failover idempotent across already-published tables

Validation

• durable restore job store: 12/12 focused tests, no leaks
• public table HTTP contract: 22/22 focused tests, no leaks
• data runtime/status generation: 7/7 focused tests, no leaks
• public API parity restore and status regressions: focused tests passed, no leaks
• table write lifecycle/forwarding production regression target passed
• backup/restore E2E file: 9 passed, 2 skipped
• managed-index delete/recreate regression: 20/20 repeated E2E passes
• metadata-leader distributed backup forwarding E2E passed
• Python SDK: 13 tests; Ruff and Pyright clean
• Go SDK tests passed
• TypeScript SDK: 116 passed, 1 skipped; typecheck passed
• OpenAPI/Zig generation remained byte-for-byte deterministic across repeated generation
• git diff --check

The complete unit and E2E matrices are left to CI; local validation intentionally used the focused targets above.