The planner could return a successful plan that omitted matching data three different ways. Each is invisible to a client, which reads a short plan as "no such data" and never revisits the range. - A block whose collection bitmask row was absent (or a segment carrying no collection index at all) was pruned. Upstream's blockHasAnyCollection returns true past the slice; degraded metadata must fail open. The fail-open now lives in the planner, not in the accessor, so inspect-segment keeps reporting membership as fact. - matchBlocks failure was `catch continue`, silently dropping the segment. It now answers 500, matching the sibling allocation path. - Allocation failure while parsing the request answered 400, telling a caller its valid request was permanently malformed. Response encoding also used `catch return` throughout, so an allocation failure mid-encode returned without ever responding. Rendering moved into renderPlan, which propagates; the handler answers 500. Tests: fail-open on absent row and absent index, exact reporting stays fail-closed, matchBlocks propagates OOM, and a fail-index sweep over the production handler asserting every response is the exact baseline plan or 5xx -- never a short 200, a 400, or a dropped request. zig build test (294), ReleaseSafe, differential-oracle, plan-config-contract. Audit: planBackfill blocked -> verified. listSegments verified -> partial; it still has the drop-on-encode pattern this commit removed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>