Found while auditing planBackfill. listSegments built its JSON with `catch return` throughout, so an allocation failure mid-encode returned without ever calling respond -- the request was dropped rather than answered. A client pages listSegments to discover the archive, so the same path could also have returned a truncated 200 that silently hides sealed segments. Rendering moves into renderSegments, which propagates; the handler answers 500. Adds the same fail-index sweep used for planBackfill. Audit: listSegments/getSegment/getBlock partial -> verified again. zig build test (297), ReleaseSafe, archive-contract against pinned client. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>