[beetlebugorg]

What changes

• Remove dims.Request.shrinkFactor. It was set to 1 and then to the shrink factor, and nothing read it. The local shrink value is what reaches importParams.
• Move EtagAlgorithm off core.Config onto the request. internal/http.Request carries it, and each endpoint sets it in its own constructor. The two private configuration copies in pkg/dims.NewHandler existed only to hold this field, so they go too.
• Remove v4.Request.HashId. See below.

Two findings while doing this

The Lambda path never set EtagAlgorithm. aws.NewRequest passes the configuration straight through, so Config().EtagAlgorithm was empty there and Etag() fell to its else branch. A /dims4/ request served by Lambda produced a sha256 ETag while the same request served by the binary produced an md5 one. Setting the field in the endpoint constructor fixes it, because both paths use that constructor.

v4.Request.HashId never ran. Etag() is defined on the embedded internal/http.Request, so its r.HashId() call binds to that type at compile time. Go does not dispatch through embedding, so the v4 override was unreachable and the client id never entered the ETag.

It is removed rather than wired up. Wiring it in would change every /dims4/ ETag and invalidate downstream caches, and it buys nothing: two client ids requesting the same commands and image URL get identical response bytes, so they should share an ETag.

Verify

TestEtagUsesMd5 and TestEtagUsesSha256 pin the digest per endpoint. Neither reads the configuration, which no longer carries the field.

The ETag output is unchanged for both endpoints. Against an origin that sends ETag: "origin-etag", before and after this change:

/v5    "795f6d862dbf9e41c8bcd6edcfde49a960755113d4947822d667bc0be3c7c665"
/dims4 "b8be214f9d0898606363a75fc42ac518"

go build ./..., go vet, and go test -race -count=1 ./... pass on the builder image.