### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

When the s3_v2 logging callback uploads a record whose S3 object key contains a character outside the RFC 3986 unreserved set — a space, #, +, &, @, unicode, etc. — the S3 PUT (and the GET on download) fails with 403 SignatureDoesNotMatch and the log record is silently dropped. This is routinely hit with s3_use_team_prefix: true (or s3_use_key_prefix: true), because the free-form team/key alias becomes the leading segment of the object key and often contains spaces or punctuation (e.g. "My Team", "R&D + Ops").

Expected: records for teams/keys whose alias contains spaces or reserved characters are uploaded to S3 successfully (object key percent-encoded and signed consistently).

Actual: every upload/download for such a key returns 403 SignatureDoesNotMatch; the record is dropped. response.raise_for_status() raises, and the broad except in the upload path logs Error uploading to s3: ... 403 Forbidden ... SignatureDoesNotMatch and swallows it — no S3 object is written and nothing is surfaced to the caller.

Root cause (double-encoding mismatch): …