### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current Behavior

I am using the latest tag for the CI/CD process and today it started to fail because unit tests for the S3 provider that cover multipart upload throw the "Expected hash not equal to calculated hash" error on uploading a part. It worked just fine with the old version. The same unit tests work correctly with the real S3 provider as well.

And there is another issue. You fixed the https://github.com/localstack/localstack/issues/8392 bug that I reported previously but there is no version on Docker Hub that has that fix but does not have the new bug I described above. It seems that you rewrite the latest tag in Docker Hub which makes it impossible to rollback to the previous version.

### Expected Behavior

1. The upload part works without throwing an exception.
2. The previous versions of Docker images are available on Docker Hub.

### How are you starting LocalStack?

With a docker-compose file

### Steps To Reproduce

1. Initiate multipart upload with the correct MD5 hash.
2. Upload a part for which the hash was calculated.

### Environment

```markdown
- OS: Windows 11
- LocalStack: latest
```


### Anything else?

_No response_
self, context: RequestContext, bucket: BucketName, expected_bucket_owner: AccountId = None
    ) -> None:
        call_moto(context)
        self._clear_bucket_from_store(bucket)
        self._cors_handler.invalidate_cache()
    def get_bucket_location(
        self, context: RequestContext, bucket: BucketName, expected_bucket_owner: AccountId = None
    ) -> GetBucketLocationOutput:
        """
        When implementing the ASF provider, this operation is implemented because:
        - The spec defines a root element GetBucketLocationOutput containing a LocationConstraint member, where
          S3 actually just returns the LocationConstraint on the root level (only operation so far that we know of).
        - We circumvent the root level element here by patching the spec such that this operation returns a
          single "payload" (the XML body response), which causes the serializer to directly take the payload element.
        - The above "hack" causes the fix in the serializer to not be picked up here as we're passing the XML body as
          the payload, which is why we need to manually do this here by manipulating the string.
        Botocore implements this hack for parsing the response in `botocore.handlers.py#parse_get_bucket_location`
        """
        response = call_moto(context)
        location_constraint_xml = response["LocationConstraint"]
        xml_root_end = location_constraint_xml.find(">") + 1
        location_constraint_xml = (
            f"{location_constraint_xml[:xml_root_end]}\n{location_constraint_xml[xml_root_end:]}"
        )
        response["LocationConstraint"] = location_constraint_xml[:]
        return response
    @handler("ListObjects", expand=False)
    def list_objects(