perf(cache-proxy): seek to range start instead of discard-reading block prefix

[EDsCODE]

Problem

In block-aligned mode, serving a range that starts mid-block opens the block file and then io.CopyN(io.Discard, ...)s its way to the slice start — reading and copying up to a full block of unwanted prefix per request. Requests almost never start on a block boundary, so a lazy scan issuing thousands of small reads pays this on nearly every one. At 8MiB blocks that's ~half a block (~4MiB) of wasted disk/page-cache reads per request, several seconds per scan, sitting on the serving path.

Benchmarks against a production table are consistent with the cost: shrinking blocks 8MiB→1MiB (which shrinks the average discard 8×) moved the fully-warm scan floor from ~6.2s to a stable ~5.3s. Seeking captures that win at any block size.

Change

Block readers come from DiskCache.openFile and are plain *os.Files, so seek to the slice start instead of discard-reading the prefix. The discard path stays as a fallback for any non-seekable reader. Response bytes are unchanged.

Testing

• go test ./cmd/cache-proxy -count=1 green; -race green for the block-aligned/drifted/concurrent tests.
• Existing drifted-range warm-hit tests assert body content for mid-block slices, which is exactly the behavior this touches.

🤖 Generated with Claude Code

[github-actions]

Test Impact Plan

Deterministic summary of how this PR changes tests, CI runners, and coverage-risk signals.

Summary

Area	Added	Changed	Deleted
Test files	0	0	0
E2E/journey files	0	0	0
Workflow files	0	0	0

Signals

• Test cases: +0 / -0
• Assertions: +0 / -0
• Skips or known failures added: 0
• Workflow continue-on-error added: 0
• Workflow path filters added: 0
• Test commands removed from justfile: 0
• E2E/journey retry lines added: 0

Coverage risk: neutral or increased

No coverage-reduction warnings detected.