fix: don't set global credential system properties for third-party S3 targets

[TheMeinerLP]

Summary

For third-party/S3-compatible endpoints (Ceph RGW, R2, MinIO, ...), credentials already travel scoped to the filesystem instance via the s3x:// URI's userInfo (accessKeyId:secretAccessKey). S3FileSystemFactory.build() additionally wrote the same credentials to the process-wide aws.accessKeyId/aws.secretAccessKey system properties unconditionally, before branching on thirdParty.

That's redundant for the third-party path, and unsafe: system properties are global mutable JVM state. Any credential resolution elsewhere in the same JVM that falls back to the default AWS credentials chain — rather than using the URI-scoped credentials this method sets up — reads whatever value was written there most recently, independent of which storage's request is actually in flight.

What prompted this

Running BlueMapS3Storage against Ceph RGW in production, I started seeing an elevated Ceph RGW failed-request-rate alert. Investigation (RGW access logs, radosgw-admin bucket stats/user info, Kubernetes secret contents) ruled out:

• Stale/rotated credentials — the access key in the mounted config matches the active RGW key exactly.
• Bucket ownership — bucket stats confirms bluemap owns the bucket.
• A recent config/deploy change — nothing changed in the days around when the failures started.

What stood out: 99.8% of the failing requests were GET .../tiles/<...> reads, rejected with no identifiable authenticated user at all (blank, not "wrong user") — and the original crash that kicked off the investigation was a 409 thrown from S3ReadAheadByteChannel (the async read-ahead path in aws-java-nio-spi-for-s3), not from the synchronous request path.

That pointed at the async path resolving credentials differently than the synchronous one — and S3FileSystemFactory writing credentials to global system properties, unconditionally, is the one place in this codebase where that kind of cross-path interference could happen.

Fix

Only set aws.accessKeyId/aws.secretAccessKey on the real-AWS-S3 branch, which has no URI-based credential mechanism and genuinely needs them. The third-party/S3X branch now relies solely on the URI-embedded credentials it already had.

Confidence level

Honest caveat: this is a hypothesis-driven fix, not a confirmed-and-reproduced one — the failure is intermittent (roughly 2-17 failed req/s in bursts, not constant), and I don't have a minimal repro isolating the exact internal code path in aws-java-nio-spi-for-s3 that falls back to the system-property-based default credentials chain. The change itself is low-risk (it only removes a redundant write on the third-party path; the real-AWS-S3 path is untouched), so I think it's worth merging and monitoring rather than blocking on a full repro.

Test plan

• ./gradlew compileJava — builds clean
• ./gradlew spotlessCheck — formatting passes
• Monitor Ceph RGW failed-request-rate after deploying this to the production server that surfaced the issue — should drop back to baseline (<1 req/s) if this was the cause