fix(smithy_aws): Retry transient transport failures (AWSHttpException)

[VarshithaPamisetty]

Description

AWSRetryer didn't retry transient transport failures (dropped handshakes, connection resets), which surface as AWSHttpException. The HTTP client now marks these as retryable via AWSHttpException.retryable(...), and the retryer retries only those.

Tests

• Unit + recovery tests: a retryable transport failure recovers; a non-transport one isn't retried.
• aws_common test: the client flags a failed connection as retryable.
• Retry-sensitive suites pass; dart analyze/format clean.
• Real S3 with an injected dropped handshake: fails without the change, passes with it.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 40.98%. Comparing base (b0c2048) to head (b691300).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7263      +/-   ##
==========================================
+ Coverage   40.97%   40.98%   +0.01%     
==========================================
  Files         121      121              
  Lines        8273     8273              
  Branches     3598     3598              
==========================================
+ Hits         3390     3391       +1     
+ Misses       4883     4882       -1     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[cadivus]

Are you sure that this is always transport-level? I see these two exceptions:

• https://github.com/aws-amplify/amplify-flutter/blob/df9817b091e42323a4050fd00b7702d3323126b9/packages/common/amplify_db_common_dart/lib/src/connect_html.dart#L74L80
• https://github.com/aws-amplify/amplify-flutter/blob/df9817b091e42323a4050fd00b7702d3323126b9/packages/common/amplify_db_common_dart/lib/src/connect_html.dart#L62L66

Should we e.g. check the exception? See if we see specific HTTP codes? We could have a look at the actual exception we want to retry.

[VarshithaPamisetty]

Good point. AWSHttpException has no status code so we can't check codes, and those two are response errors, not transport. Instead of trusting the type, the HTTP client now marks the real transport failures with AWSHttpException.retryable(...) and the retryer only retries the flagged ones, so those two stay non-retryable.

Should we check the HTTP code before setting the exception to retryable? Or even catch more fine granular?