P2: Answer byte ranges on raw file downloads

Why

/r/<name>/raw/<ref>/<path> streams the whole blob and does not implement byte ranges: it sets Content-Length and copies, with no Accept-Ranges and no handling of Range. A client resuming a download, or a player asking for a few KiB, gets the whole file every time.

Measured in #100 with the load harness, an 8 MiB blob and Range: bytes=0-65535:

The artifact route already answers ranges because it uses http.ServeContent over a file. /raw streams from git cat-file, which cannot seek.

Scope

• Answer a single Range: bytes=a-b (and a-, -n) with 206, Content-Range, and only the requested bytes. Advertise Accept-Ranges: bytes on the response.
• A request without Range stays exactly as it is: 200, Content-Length, the whole blob.
• An unsatisfiable range (a past the end) is 416 with Content-Range: bytes */<size>.
• Multiple ranges may be answered with the whole file (200); it is allowed and keeps the reader simple.
• Reading a range still costs the bytes before it in the git stream; skipping is a copy into a discard buffer, not a seek. The win is what crosses the network, and it should be said in the code comment.

Acceptance

• curl -r 0-1023 on a raw file returns 206, Content-Range: bytes 0-1023/<size>, Accept-Ranges: bytes, and 1024 bytes.
• The no-range response is byte-for-byte what it is now.
• Tests cover a prefix range, a suffix range, an unsatisfiable range, and a file smaller than the range.
• The load harness raw-range scenario shows 206 and a body the size of the range.

Part of #100. The measurement and the comparison with the artifact route are recorded there.