Upon further investigation, I have figured out the cause of the issue:
The example blob config for an s3 compatible api included the parameter disableSSL=true and I naively assumed that this was necessary for compatibility reasons. The SDK attempted to PUT my new file in place and got a 301 redirect to try the PUT again at the https protocol. Something inside the sdk then decided to GET the file from that new address instead of retrying the PUT and it was sending the GET request with the same x-amz-content-sha256 as the previous PUT request. This is guaranteed to fail, as this header is computed based on the request, including HTTP verb (GET/PUT) and the canonical URI (including http/https)
Once I removed the disableSSL=true from my s3 compatible URI in my deploy config, it no longer attempted http requests, and the PUT succeeded on the first try.