Add a byte[]-based uploadFile overload; hide the Iterator<byte[]> chunking as an internal implementation detail

### Problem

`S3Client.uploadFile(String objectKey, String storageClass, Iterator contentIterable, String contentType)` is currently the only entry point for binary uploads. This forces any caller that already has the full content buffered as a single `byte[]` to hand-write a throwaway single-use `Iterator` just to satisfy the signature.

### Solution

Add a public overload:

```java
void uploadFile(String objectKey, String storageClass, byte[] content, String contentType) throws S3ResponseException, IOException;
```

Internally this wraps content in Bucky's own private single-element Iterator and delegates to the existing multipart-capable method. Callers with an in-memory array never need to implement Iterator themselves: it's an internal detail, not something exposed at the API boundary.

### Alternatives

_No response_

Start in S3Client with the existing uploadFile(String, String, Iterator, String) entry point and trace its current multipart upload behavior. Add the requested byte[] overload while keeping iterator construction internal and delegating to the existing method. Done means callers can pass a byte[] directly without implementing an Iterator, with existing upload behavior preserved.

Written by the indexing model from the issue text.