S3 remote signer clients share auth and HTTP state across catalogs

> This issue was reported to the private Apache Iceberg security mailing list. The submitter is being kept anonymous because the report was sent to a private list. After review, the issue is not considered a serious vulnerability that needs to be kept private, so it is being filed publicly here for tracking and resolution.
>
> Note: this submission was generated by AI. Please review its claims and source references carefully before acting on them.

# Summary

The AWS remote signer client keeps auth and HTTP state in static
process-wide fields, so one catalog can leak headers or auth behavior
into another.

# Affected Maven coordinates

* primary shipped client artifact: `org.apache.iceberg:iceberg-aws`
* bundle artifact: `org.apache.iceberg:iceberg-aws-bundle`

# Attacker prerequisites

* a shared process that talks to more than one catalog or reuses
cached table state
* ability to trigger the affected initialization or cache-reuse path

# Impact

* Cross-tenant leakage of custom auth headers or tokens to the wrong
signer service
* Authentication confusion when multiple catalogs use different auth mechanisms
* Hard-to-detect authorization failures or unintended access if two
catalogs share one JVM

# Proof status

Source review only. The issue is visible directly from source.

# Key source references

* org.apache.iceberg.aws.s3.signer.S3V4RestSignerClient

Start with org.apache.iceberg.aws.s3.signer.S3V4RestSignerClient in the iceberg-aws artifact, then compare how its static authentication and HTTP state is initialized and reused across catalogs. Confirm the reported cross-catalog leakage behavior and define done as keeping each catalog's headers, credentials, and authentication behavior isolated; review the bundle artifact as needed.

Written by the indexing model from the issue text.