[tamirms]

What

A panic on one of the cold read path's background goroutines now fails the request instead of ending the process.

• A ReadItems worker recovers a panic into a packfile.PanicError and keeps its record workspace out of the pool, since the workspace may be half written.
• The MPHF load in OpenColdReader sends a panic the same way, as its load error.
• The packfile open goroutine only swallows a panic, because sync.OnceValue repeats it in the request's own waitOpen call, where the bridge recovers it.

A PanicError's message is only the operation and "panicked", because queryEvents and getEvents copy internal error messages into client responses. The panic value and stack ride on the error, and both handlers log them as fields when they log the failure.

Tests: TestReadItemsWorkerPanicIsAnError makes a worker panic and requires a plain error that carries the value and stack, and a reader that keeps serving; TestWithPanicLogsValueAndStack requires the handlers' log entry to carry both.

Why

The bridge turns a handler panic into a failed request and logs its stack, but these three goroutines run outside its recover, so a panic in any of them exits the process. The ReadItems workers run on the request path since #1086 reads cold data 8 at a time; the other two predate this stack. No input is known to make them panic: records carry CRC32C, zstd checks its frames, and counts are checked at open. A bug that does panic now fails the requests that reach it and logs its stack, the same trade the bridge makes for handler panics.

🤖 Generated with Claude Code