Fix CRT S3 getObject file handling

[davidh44]

Motivation and Context

PR #6289 changed the CRT getObject(request, Path) overload in 2.32.11 to write directly to the destination through CRT. This unintentionally changed its file-handling behavior: existing destinations could be silently replaced, and failed downloads could leave truncated or stray files.

The direct getObject(request, Path) overload and getObject(request, AsyncResponseTransformer.toFile(path)) on the same client currently behave differently. This change restores the documented behavior and makes them consistent.

This is a behavioral compatibility change for callers relying on implicit replacement since 2.32.11. Those callers can retain replacement behavior with AsyncResponseTransformer.toFile(path, FileTransformerConfiguration.defaultCreateOrReplaceExisting()).

Modifications

• Preserve existing destinations and complete the returned future with FileAlreadyExistsException before sending an HTTP request.
• Delete files created by downloads that fail or are cancelled.
• Propagate request-scoped CRT file options without changing Transfer Manager's defaults.

Testing

Added unit tests

Types of changes

• Bug fix
• New feature

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

• I confirm that this pull request can be released under the Apache 2 license