Register the S3 request signer on the session

[m0g3r]

Closes #3625

Rationale for this change

FsspecFileIO remote request signing (s3.signer=S3V4RestSigner) silently stops signing on
current aiobotocore/s3fs. _s3() builds the filesystem first and then attaches the signer to
fs.s3:

fs = S3FileSystem(**s3_fs_kwargs)
for event_name, event_function in register_events.items():
    fs.s3.meta.events.unregister(event_name, unique_id=1925)
    fs.s3.meta.events.register_last(event_name, event_function, unique_id=1925)

Touching fs.s3 forces one eager client, but the client that actually issues requests is created
lazily inside the running event loop by S3FileSystem.set_session, and it does not inherit
handlers registered on that earlier client. Since config_kwargs["signature_version"] is set to
UNSIGNED, requests then go out with no Authorization header and S3 rejects them with
InvalidRequest: The authorization mechanism you have provided is not supported.

This change registers the signer on an aiobotocore session and passes that session to
S3FileSystem, so every client the session creates carries the handler. register_last and the
unique_id are kept, so ordering relative to the stock before-sign.s3 handlers is unchanged.
The unregister call is dropped because a freshly created session has nothing registered under
that id.

Credit for the diagnosis and the proposed approach goes to the issue reporter.

Are these changes tested?

Yes. test_s3v4_rest_signer_registered_on_session is added to tests/io/test_fsspec.py. It
builds the FileIO with a signer configured, takes the session handed to S3FileSystem, emits
before-sign.s3 on it, and asserts the REST signer ran — the request URL is rewritten and an
Authorization header is set. On main it fails with KeyError: 'session', since no session is
passed today.

The mechanism was also confirmed directly against s3fs 2026.4.0 and aiobotocore 3.8.0 by
driving set_session() and inspecting the handlers on the client that ends up issuing requests:

register on fs.s3      -> handler present on the real client: False
register on session    -> handler present on the real client: True

• make lint — passes, including mypy
• make test — 3804 passed, 3 skipped

Not verified end to end against a live REST catalog with remote signing and real S3, as that
needs credentials and an S3 endpoint that enforces SigV4; moto does not. The end-to-end
confirmation in the issue report covers that path.

Are there any user-facing changes?

No API change. Remote signing starts working again on current dependency versions, so
FsspecFileIO users on a modern aiobotocore will see requests signed rather than rejected.

AI assistance

Claude Code was used to investigate the issue, write the change and the test, and run the
verification described above. The full diff was reviewed before submission.

[paulcaron16k]

This also fixes #3896, which is a second, independent reason the unregister on line 237 is wrong: _s3() removes the signer and re-registers it on an emitter fsspec caches and every thread shares, so a request signed in that window goes out unsigned and the store answers 403 AccessDenied — distinct from the InvalidRequest this PR describes, and reached without any lazily-created client being involved.

Your change closes it because it drops the unregister entirely. I verified that rather than assuming: applied this PR and ran two tests that fail on main and pass with it —

• test_s3_leaves_a_signer_installed_while_reconfiguring_a_shared_client — observes the shared emitter the instant _s3() unregisters
• test_the_signer_stays_installed_while_another_thread_reconfigures_s3 — the same window from another thread

Both are in tests/io/test_fsspec.py, need no credentials or network, and check they are not passing vacuously under this PR (the signer is still visible on fs.s3.meta.events, since the client inherits the session's handlers).

They are on #3896 if useful. Happy to raise them against this PR instead so the fix and its regression cover land together — your call, and no action needed from you either way.