Concurrent Iceberg reads can lose their S3 request signer #9128

What happened?

Concurrent Iceberg materialization reads can fail with 403 AccessDenied and leave a loop waiting for input. PyIceberg replaces the request signer on an S3 filesystem that fsspec shares across FileIO instances. A read during that replacement goes out unsigned.

Before: a second table initializes its filesystem and interrupts an existing signed read.
After: each FileIO keeps its own signer while retaining its per-thread filesystem cache.

Reproduced with real S3 reads against an isolated RustFS rc.6 and Lakekeeper 0.11.0 stack. The read succeeds before replacement, fails during the controlled gap, and succeeds again after registration finishes. Related upstream report: apache/iceberg-python#3896.

How to reproduce?

1. Use the REST Iceberg catalog with remote S3 signing and PyIceberg 0.11.1.
2. Create two tables and append one row to each.
3. Load both tables into separate FileIO instances. Read the first table's Parquet file successfully.
4. Pause the second filesystem initialization between unregistering and registering before-sign.s3.
5. Read the first file again. It fails with AccessDenied. Resume signer registration and the same read succeeds.

The same error appears in the failed integration job on #8957. The timestamp change there is unrelated.

Version/Branch

1.4.0-incubating-SNAPSHOT (main)

Commit Hash (Optional)

98c6337

Relevant log output

Initial real signed S3 read passed
Reproduced real S3 read failure: Forbidden
Same signed S3 read passed again after signer registration