fix(objectstore): Add retry logic and structured error handling to S3 readObject()

[joshtrichards]

• Resolves: #

Summary

readObject() bypasses the AWS SDK's HTTP transport to enable seekable reads via HTTP range requests (SeekableHttpStream). A side effect is that the SDK's retry middleware and error parsing -- configured via retriesMaxAttempts -- have no effect on read operations. This means transient S3 failures (503, 429,
connection timeouts) cause immediate failure, and all errors surface as the generic "Failed to read object" with no S3 error context.

Changes:

• Retry with backoff and jitter for transient failures (5xx, 429) and connection-level errors, honoring the existing retriesMaxAttempts config
• ignore_errors stream context option so fopen() returns a stream on 4xx/5xx instead of bare false, allowing inspection of the actual response
• S3 error response parsing -- extracts error code, message, x-amz-request-id, and x-amz-id-2 from both the XML body and response headers
• Per-attempt logging at warning for retryable failures (visible even when retries succeed) and error for terminal failures
• Improved exception messages including attempt count and structured S3 error detail instead of "Failed to read object $urn"
• Correct status code parsing -- scans wrapper_data in reverse to handle 100 Continue / redirect / proxy response chains

Context:

See PR #20033 for the original motivation behind the SeekableHttpStream approach. The SDK bypass remains necessary for seekable range-request streams; this change brings the error handling closer to parity with what the SDK provides for all other S3 operations.

Not in scope:

• Refactoring logger access across S3ConnectionTrait / S3ObjectTrait into a shared abstract method (flagged with a TODO for a follow-up)
• Response checksum validation and permanent redirect handling, which are also bypassed but require deeper architectural changes

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI