DynamoDB ExecuteStatementOutput.items order is non-deterministic

### Describe the bug

The `aws-sdk-dynamodb::Client.execute_statement()` function allows a SQL query to be executed (e.g. `SELECT id, name FROM users`) where the caller can specify columns/attributes with an explicit order. The `ExecuteStatementOutput.items` specifies the results using a `HashMap` which does not guarantee the order of the columns. When the SQL is based on user input, they expect the columns to be returned in the order they specify (e.g. `id`, `name`), and not in an arbitrary order (e.g. `name`, `id`).

### Regression Issue

- [ ] Select this option if this issue appears to be a regression.

### Expected Behavior

Attributes returned in `ExecuteStatementOutput.items` should be in the order specified by the user when explicitly specified, or the table definition when `*` is used.

### Current Behavior

Attribute are returned in a non-deterministic order.

### Reproduction Steps

Test program that reproduces the issue: [dynamodb.zip](https://github.com/user-attachments/files/19494234/dynamodb.zip)

### Possible Solution

I have only looked at the interfaces for the API. Perhaps a place to start is to define `ExecuteStatementOutput.items` to be `IndexMap`.

### Additional Information/Context

_No response_

### Version

```text
├── aws-config v1.6.1
│ ├── aws-credential-types v1.2.2
│ │ ├── aws-smithy-async v1.2.5
│ │ ├── aws-smithy-runtime-api v1.7.4
│ │ │ ├── aws-smithy-async v1.2.5 (*)
│ │ │ ├── aws-smithy-types v1.3.0
│ │ ├── aws-smithy-types v1.3.0 (*)
│ ├── aws-runtime v1.5.6
│ │ ├── aws-credential-types v1.2.2 (*)
│ │ ├── aws-sigv4 v1.3.0
│ │ │ ├── aws-credential-types v1.2.2 (*)
│ │ │ ├── aws-smithy-http v0.62.0
│ │ │ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ │ │ ├── aws-smithy-types v1.3.0 (*)
│ │ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ │ ├── aws-smithy-types v1.3.0 (*)
│ │ ├── aws-smithy-async v1.2.5 (*)
│ │ ├── aws-smithy-http v0.62.0 (*)
│ │ ├── aws-smithy-runtime v1.8.1
│ │ │ ├── aws-smithy-async v1.2.5 (*)
│ │ │ ├── aws-smithy-http v0.62.0 (*)
│ │ │ ├── aws-smithy-http-client v1.0.1
│ │ │ │ ├── aws-smithy-async v1.2.5 (*)
│ │ │ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ │ │ ├── aws-smithy-types v1.3.0 (*)
│ │ │ │ │ │ ├── aws-lc-rs v1.12.6
│ │ │ │ │ │ │ ├── aws-lc-sys v0.27.1
│ │ │ │ │ │ │ ├── aws-lc-rs v1.12.6 (*)
│ │ │ ├── aws-smithy-observability v0.1.2
│ │ │ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ │ ├── aws-smithy-types v1.3.0 (*)
│ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ ├── aws-smithy-types v1.3.0 (*)
│ │ ├── aws-types v1.3.6
│ │ │ ├── aws-credential-types v1.2.2 (*)
│ │ │ ├── aws-smithy-async v1.2.5 (*)
│ │ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ │ ├── aws-smithy-types v1.3.0 (*)
│ ├── aws-sdk-sso v1.63.0
│ │ ├── aws-credential-types v1.2.2 (*)
│ │ ├── aws-runtime v1.5.6 (*)
│ │ ├── aws-smithy-async v1.2.5 (*)
│ │ ├── aws-smithy-http v0.62.0 (*)
│ │ ├── aws-smithy-json v0.61.3
│ │ │ └── aws-smithy-types v1.3.0 (*)
│ │ ├── aws-smithy-runtime v1.8.1 (*)
│ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ ├── aws-smithy-types v1.3.0 (*)
│ │ ├── aws-types v1.3.6 (*)
│ ├── aws-sdk-ssooidc v1.64.0
│ │ ├── aws-credential-types v1.2.2 (*)
│ │ ├── aws-runtime v1.5.6 (*)
│ │ ├── aws-smithy-async v1.2.5 (*)
│ │ ├── aws-smithy-http v0.62.0 (*)
│ │ ├── aws-smithy-json v0.61.3 (*)
│ │ ├── aws-smithy-runtime v1.8.1 (*)
│ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ ├── aws-smithy-types v1.3.0 (*)
│ │ ├── aws-types v1.3.6 (*)
│ ├── aws-sdk-sts v1.64.0
│ │ ├── aws-credential-types v1.2.2 (*)
│ │ ├── aws-runtime v1.5.6 (*)
│ │ ├── aws-smithy-async v1.2.5 (*)
│ │ ├── aws-smithy-http v0.62.0 (*)
│ │ ├── aws-smithy-json v0.61.3 (*)
│ │ ├── aws-smithy-query v0.60.7
│ │ │ ├── aws-smithy-types v1.3.0 (*)
│ │ ├── aws-smithy-runtime v1.8.1 (*)
│ │ ├── aws-smithy-runtime-api v1.7.4 (*)
│ │ ├── aws-smithy-types v1.3.0 (*)
│ │ ├── aws-smithy-xml v0.60.9
│ │ ├── aws-types v1.3.6 (*)
│ ├── aws-smithy-async v1.2.5 (*)
│ ├── aws-smithy-http v0.62.0 (*)
│ ├── aws-smithy-json v0.61.3 (*)
│ ├── aws-smithy-runtime v1.8.1 (*)
│ ├── aws-smithy-runtime-api v1.7.4 (*)
│ ├── aws-smithy-types v1.3.0 (*)
│ ├── aws-types v1.3.6 (*)
├── aws-credential-types v1.2.2 (*)
├── aws-sdk-dynamodb v1.70.0
│ ├── aws-credential-types v1.2.2 (*)
│ ├── aws-runtime v1.5.6 (*)
│ ├── aws-smithy-async v1.2.5 (*)
│ ├── aws-smithy-http v0.62.0 (*)
│ ├── aws-smithy-json v0.61.3 (*)
│ ├── aws-smithy-runtime v1.8.1 (*)
│ ├── aws-smithy-runtime-api v1.7.4 (*)
│ ├── aws-smithy-types v1.3.0 (*)
│ ├── aws-types v1.3.6 (*)
```

### Environment details (OS name and version, etc.)

MacOS Sequoia 15.3.2

### Logs

_No response_

Start at the generated aws-sdk-dynamodb ExecuteStatementOutput type and the execute_statement API entry point, then trace how items are represented and decoded. Check whether the service response carries a meaningful attribute order and identify the existing DynamoDB tests; done means returned attributes preserve the requested order, including the table-definition order for SELECT *.

Written by the indexing model from the issue text.