fix(restore): resume S3 streams on drop

[corylanou]

Summary

Add a resumable reader for S3-compatible restores and a Docker integration test that reproduces connection drop EOFs.

Fixes #1077

Problem

Large restores can keep some S3-compatible streams idle long enough for providers to close connections, leading to "unexpected EOF" during restore.

Solution

Use a resumable reader that reopens LTX streams on read errors/premature EOF and add a MinIO + Toxiproxy integration test to reproduce the issue.

Scope

In scope:

• Resumable reader used during restore
• Docker integration test for S3-compatible connection drops

Not in scope:

• Provider-specific timeout tuning
• Changes to compactor ordering

Test Plan

• go test -v -count=1 -tags=integration,docker -run TestRestore_S3ConnectionDrop ./tests/integration

Credits

• Thanks to @emschwartz for identifying this issue and contributing the original fix in Handle S3 connection drops during restores of large databases #1080

[corylanou]

Manual verification (Docker):

1. Repro (old binary):

• go test -v -count=1 -tags=integration,docker -run TestRestore_S3ConnectionDrop ./tests/integration
• Result: restore failed with unexpected EOF (decode page header) when using a bin/litestream built before the resumable reader.

2. Fix (this branch):

• go build -o bin/litestream ./cmd/litestream
• go test -v -count=1 -tags=integration,docker -run TestRestore_S3ConnectionDrop ./tests/integration
• Result: PASS.

Note: the first run failed because the test uses the on-disk bin/litestream binary; rebuilding after applying the fix makes the test pass.