fix: resume or reject premature EOF from resumable HTTP responses

[digizeph]

Problem

ResumableHttpReader::read currently treats Ok(0) from the active HTTP response as a clean EOF without comparing the consumed byte offset to the original Content-Length.

Most premature HTTP disconnects are expected to surface as a read error and therefore resume correctly. However, if the HTTP stack reports an early close as Ok(0), a response with a known larger Content-Length could be accepted as a silently truncated stream.

Proposed behavior

When read receives Ok(0) and the original response declared a length greater than the current raw-byte offset:

1. Treat the response as incomplete.
2. Attempt the normal validated Range resume from the current offset.
3. Return an error if the resource cannot be safely resumed.

A 416 response remains EOF only when the current offset is at or beyond the declared content length.

Acceptance criteria

• A response that ends before its declared Content-Length either resumes successfully or returns an error.
• The reader never returns clean EOF while a known declared length remains unread.
• Normal EOF and unknown-length chunked responses retain their current behavior.
• Add a scripted HTTP-server regression test for the premature-EOF path.