S3 remote signer signed-request cache can reuse signatures across principals in one JVM

> After review, this is not considered a serious vulnerability that needs to be kept private, so it is being filed publicly here for tracking and resolution. It is the same general class as #16460 (`S3V4RestSignerClient` process-wide state). Open PR #16524 isolates static `AuthManager` / `HTTP` client state; it does not change the signed-request cache.

# Summary

`S3V4RestSignerClient` keeps a process-wide signed-request cache keyed only by HTTP method, region, and URI (30s TTL, populated when the signer responds `Cache-Control: private`). A later principal in the same JVM that requests the same URI can receive the first principal’s SigV4 headers without a new sign call.

# 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 using S3 remote signing with more than one principal or catalog
* two sign requests for the same method + region + URI within the cache TTL
* signer response that allows caching (`Cache-Control: private`)

# Impact

* A principal whose signer would refuse the request can still obtain a previously cached signature for that URI
* Cross-principal confusion in shared-JVM engines (e.g. a multi-tenant Spark server)

# Proof status

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

# Key source references

* `org.apache.iceberg.aws.s3.signer.S3V4RestSignerClient` (`SIGNED_COMPONENT_CACHE`, cache key)

# Related

* #16460 — static auth/HTTP fields (same class of bug)
* #16524 — fix for #16460; does not address this cache

Start with org.apache.iceberg.aws.s3.signer.S3V4RestSignerClient, especially SIGNED_COMPONENT_CACHE and its cache key. Trace how signed requests are cached when the signer returns Cache-Control: private, then inspect existing tests around this client. Done means signatures cannot be reused across principals or catalogs in the same JVM, with regression coverage for the reported scenario.

Written by the indexing model from the issue text.