fix: include Content-Length in fastly HEAD responses

[lf-]

I hit an extremely strange issue while working on buck2: I got an error implying I needed to explicitly specify a content length while downloading crates at content-addressed paths. I dug through the code, realized there was a fallback path of making a HEAD request to get the length, then pulled out curl and went "wtf".

This only happens on fastly:

$ curl --head 'https://fastly-static.crates.io/crates/adler2/2.0.1/download' | grep -i content-
content-type: application/gzip

$ curl --head 'https://cloudfront-static.crates.io/crates/adler2/adler2-2.0.1.crate' | grep -i content-
content-type: application/gzip
content-length: 13366

With a GET request of an empty range, the content length is correct:

$ curl -sS -D - -o /dev/null --http1.1 -H 'Range: bytes=0-0' 'https://static.crates.io/crates/adler2/2.0.1/download' | grep -i content-
Content-Length: 13366
content-type: application/gzip

Validation: I'm terribly sorry; I don't know how to add automated tests to this project that would actually test this. It seems like it's not compatible with viceroy, due to Request::set_after_send not being supported; this implies to me that the test infra necessary to write an automated test doesn't exist.

For what it's worth, I have thrown an agent at making throwaway garbage LLM harness code that seems to validate this change does cause it to start sending Content-Length on HEAD requests where it did not before (I will spare you that code. it's not good). It cfg'd out calling set_surrogate_keys which apparently was pretty much all that was needed to get this crate to work on Viceroy, fyi, in case you do want to build a test suite.