fix: HEAD no longer downloads the full body from GCS

[daichirata]

Summary

Resolves #59 (reported by @MN755).

Previously, HEAD requests fell through the same code path as GET: `streamObject` / `streamRange` would open a `*storage.Reader` and call `io.Copy(w, objr)`. `net/http` does discard the body for HEAD, but the Read side of `io.Copy` still pulled every byte from GCS — so a `HEAD` on a 1 GB object racked up the same GCS read latency, egress, and billing as a `GET`.

Fix

Both `streamObject` and `streamRange` now short-circuit before opening a GCS reader when `r.Method == http.MethodHead`. Headers are derived from the object attrs we already have:

• `Content-Encoding` / `Content-Length` are reconstructed from `attrs` + the client's `Accept-Encoding` so they match what a matching `GET` would produce.
• The full Range parsing pipeline still runs first, so HEAD-with-Range correctly returns `206` / `416` / falls through to `200` under the same conditions as GET-with-Range.

Test plan

New focused HEAD tests sit alongside the existing GET / Range coverage:

Test	Scenario	Asserts
`TestProxy_HEAD_NoBody`	plain HEAD	200, body length 0, `Accept-Ranges: bytes`
`TestProxy_HEAD_ContentLengthOptIn`	HEAD with `-content-length`	`Content-Length` set, body length 0
`TestProxy_HEAD_NotFound`	HEAD on missing object	404
`TestProxy_HEAD_Range`	HEAD + Range	206, `Content-Range`, body length 0
`TestProxy_HEAD_Range_Unsatisfiable`	HEAD + out-of-bounds Range	416
`TestProxy_HEAD_Range_NonBytesUnitIgnored`	HEAD + `items=0-10`	200, body length 0
`TestProxy_HEAD_GzippedObject`	HEAD on gzip-stored, both with and without `Accept-Encoding: gzip`	correct `Content-Encoding` derivation

• `go test -race -count=1 ./...` passes
• `go vet ./...` / `go build ./...` pass
• CI green on this PR

Also tightens a couple of comments in `streamRange` that had grown longer than they needed to be.

🤖 Generated with Claude Code