feat: support the AWS default credential chain for S3 connectors

## Problem

The S3 source and target connectors require `access_key` and `secret_key` in every request and pass them explicitly to boto3. This prevents deployments on AWS from using the standard boto3 credential provider chain, including ECS task roles, EKS Pod Identity/IRSA, and EC2 instance profiles.

Passing long-lived AWS credentials in an API payload is unnecessary and increases the risk of exposure through request handling and logs.

## Proposed behavior

- Make `access_key` and `secret_key` optional as a pair.
- When explicit credentials are omitted, construct the boto3 client/resource without credential arguments so boto3 uses its standard credential provider chain.
- Preserve the existing explicit credential flow for S3-compatible services such as MinIO and IBM COS.
- Reject partial explicit credentials with a clear validation error.

## Expected tests

- Explicit access/secret credentials remain supported.
- Omitted credentials delegate to boto3's default provider chain.
- Supplying only one of access key or secret key is rejected.
- Source and target connectors share the same behavior.

I am working on a pull request for this change.

Start by locating the S3 source and target connector entry points and their boto3 client/resource construction. Run the connector tests, then cover explicit credentials, omitted credentials using boto3's default provider chain, and partial credentials that must fail validation. Done means both connectors share the specified behavior without requiring credentials for AWS deployments.

Written by the indexing model from the issue text.