build(deps): bump the simple1 group with 11 updates

[dependabot]

Bumps the simple1 group with 11 updates:

Package	From	To
aws-config	1.8.13	1.8.15
aws-credential-types	1.2.11	1.2.14
aws-types	1.3.11	1.3.14
aws-smithy-runtime-api	1.11.3	1.11.6
aws-smithy-runtime	1.10.0	1.10.3
aws-smithy-types	1.4.3	1.4.7
aws-sigv4	1.3.8	1.4.2
aws-sdk-sts	1.97.0	1.101.0
aws-runtime	1.6.0	1.7.2
aws-smithy-async	1.2.11	1.2.14
aws-smithy-http	0.63.3	0.63.6

Updates aws-config from 1.8.13 to 1.8.15

Commits

• See full diff in compare view

Updates aws-credential-types from 1.2.11 to 1.2.14

Commits

• See full diff in compare view

Updates aws-types from 1.3.11 to 1.3.14

Commits

• See full diff in compare view

Updates aws-smithy-runtime-api from 1.11.3 to 1.11.6

Commits

• See full diff in compare view

Updates aws-smithy-runtime from 1.10.0 to 1.10.3

Commits

• See full diff in compare view

Updates aws-smithy-types from 1.4.3 to 1.4.7

Commits

• See full diff in compare view

Updates aws-sigv4 from 1.3.8 to 1.4.2

Changelog

Sourced from aws-sigv4's changelog.

March 16th, 2026

New this release:

• 🐛 (client) Fix null value handling in dense collections: SDK now correctly rejects null values in non-sparse collections instead of silently dropping them.

March 2nd, 2026

New this release:

• 🐛 (client, smithy-rs#4429) Fix bug where initial-request messages in event stream operations are not signed.

February 16th, 2026

New this release:

• 🎉 (server, smithy-rs#4494) Automatically add smithy.framework#ValidationException to operations with constrained inputs. Previously, users had to either set addValidationExceptionToConstrainedOperations: true in codegen settings or manually add ValidationException to each operation. Now this happens automatically unless a custom validation exception (a structure with the @validationException trait) is defined in the model. When using a custom validation exception, users must explicitly add it to each applicable operation. The addValidationExceptionToConstrainedOperations flag is deprecated.

February 10th, 2026

Breaking Changes:

• ⚠️ (all) Upgrade MSRV to Rust 1.91.0.

February 1st, 2026

Breaking Changes:

• ⚠️🎉 (client, smithy-rs#4454, smithy-rs#4467, aws-sdk-rust#1389) Enable retries by default for AWS SDK clients using BehaviorVersion::v2026_01_12() or later.

  Previously, retries were only enabled when constructing clients via aws_config::load_from_env(). Clients constructed directly using Client::from_conf() did not have retries enabled, which was inconsistent with AWS SDK behavior in other languages.

  This change affects AWS SDK clients constructed with Client::from_conf() when using BehaviorVersion::v2026_01_12() or BehaviorVersion::latest(). Generic Smithy clients (non-AWS) are not affected.

  To disable retries:

  let config = aws_sdk_s3::Config::builder()
      .retry_config(RetryConfig::disabled())
      // ...
      .build();

  For more context, see the discussion on retry behavior.

New this release:

• 🎉 (client, smithy-rs#312, @​AmitKulkarni23) Add support for Smithy bigInteger and bigDecimal types as string wrappers in aws-smithy-types, allowing users to parse with their preferred big number library.
• 🎉 (all, smithy-rs#4484) All Smithy-rs crates, for both servers and clients, now use the 1.x version of the http crate for all internal processing. Utility methods are still provided for users to convert between SDK types and both of the http 0.x and 1.x types.
• 🐛 (client, smithy-rs#4500) Fix JMESPath integer literal handling in waiters to support Smithy 1.66.0, which parses integer literals as Long instead of Double.

... (truncated)

Commits

• See full diff in compare view

Updates aws-sdk-sts from 1.97.0 to 1.101.0

Commits

• See full diff in compare view

Updates aws-runtime from 1.6.0 to 1.7.2

Commits

• See full diff in compare view

Updates aws-smithy-async from 1.2.11 to 1.2.14

Commits

• See full diff in compare view

Updates aws-smithy-http from 0.63.3 to 0.63.6

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

[github-actions]

Thanks for opening this PR! Here are a few tips to help make the review process smooth for everyone.

PR title guidelines

• Use imperative mood: "Fix X" not "Fixed X" or "Fixes X"
• Be specific: "Fix panic in catalog sync when controller restarts" not "Fix bug" or "Update catalog code"
• Prefix with area if helpful: compute: , storage: , adapter: , sql:

Pre-merge checklist

• The PR title is descriptive and will make sense in the git log.
• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).

[bosconi]

Looks good.

[dependabot]

Looks like these dependencies are updatable in another way, so this is no longer needed.