Shutdown internally-created executor on error in TransferManager

[bhoradc]

Fixes #3419

Description

TransferManager shuts down its internally-created DefaultExecutor after the operation completes. Because the shutdown call is not in an ensure block, any error raised during the transfer skips it, leaving the executor's worker threads parked on its internal queue forever. In long-running processes with repeated failures this accumulates until
thread or memory limits are hit.

Present in all five methods that create an internal executor:
upload_file, upload_stream, download_file, upload_directory, download_directory.

Fix

Wrap each operation body in begin/ensure so executor.shutdown unless @executor runs on both success and error paths. The unless @executor guard is preserved, so custom executors remain the caller's
responsibility. DefaultExecutor#shutdown is idempotent, so no double-shutdown risk.

Testing

Added one regression spec per method. Each stubs a failure, captures the internally-created DefaultExecutor, and asserts shutdown was called on it. All five fail on main and pass with this change.

Locally ran the full CI-equivalent suite (rake build, rake test:spec, rbs collection install && rake rbs:test) - all green.

AI-assisted and manually reviewed.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[github-actions]

Detected 1 possible performance regressions:

• aws-sdk-cloudwatchlogs.put_log_events_small_allocated_kb - z-score regression: 58.68 -> 58.82. Z-score: Infinity

[jterapin]

Once you address the below comment regarding object customization, we should be good to approve.

Unrelated: I found some bugs relating to TM so I will have a fix out shortly.

[jterapin]

LGTM, thank you!