Content-Length is ignored for object storage responses

ObjectReader.ContentLength() returns -1 for every object storage response that has a valid Content-Length header, because of an inverted error check.

https://github.com/imgproxy/imgproxy/blob/faf382077474eee3c406fa85e8007d340619be12/storage/reader.go#L96-L110

p, err := strconv.ParseInt(h, 10, 64)
if err != nil {
    return p
}

When ParseInt succeeds err is nil, so this branch is skipped and the parsed value is dropped, and the function falls through to return -1. When it fails it returns p, which is 0 for a syntax error. So the real length is never returned.

The S3, Google Cloud Storage, Azure Blob Storage and Swift backends all report the size through the Content-Length header and leave the internal contentLength field at -1, so res.ContentLength ends up -1 for all of them.

The visible effect is that the IMGPROXY_MAX_SRC_FILE_SIZE limit can no longer be checked before the download starts (limitResponseSize compares -1 > limit), so an oversized object is streamed and only cut off mid-download by the hard limit reader. The async buffer also can no longer tell when a storage response was truncated, and the sync download skips its buffer preallocation.

I have a one-line fix and a test ready and can open a PR.