Transform custom Remote execution doesn't support ARM64/Graviton - pre-built image and Batch job definition are x86_64 only

### Describe the feature

The remote execution path on the `atx-remote-infra` branch can't run Arm64 transformation jobs. (Consumed by the `aws-transform` skill in [aws/agent-toolkit-for-aws/skills/migration-and-modernization-skills](https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/migration-and-modernization-skills/aws-transform), which clones this branch at runtime.)

The `AWS/early-access-java-x86-to-graviton` TD can rewrite source/Dockerfiles, but any build/test verification that runs inside the Fargate container after the transformation always executes on x86 - so a Graviton migration can't be end-to-end validated remotely.

Where the gap is
1. Pre-built ECR image is single-arch amd64.
The default `prebuiltImageUri` in [cdk.json](https://github.com/aws-samples/aws-transform-custom-samples/blob/atx-remote-infra/cdk.json) points to `public.ecr.aws/d9h8z6l7/aws-transform:latest`. Inspecting the manifest:

```
schemaVersion: 2
mediaType: application/vnd.docker.distribution.manifest.v2+json # not a multi-arch index
config.architecture: amd64
config.os: linux
```

There is no `arm64` variant published.

2. Dockerfile is hard-coded to x86_64.
[container/Dockerfile](https://github.com/aws-samples/aws-transform-custom-samples/blob/atx-remote-infra/container/Dockerfile):

- `ENV JAVA_HOME=/usr/lib/jvm/java-17-amazon-corretto.x86_64`
- `awscli-exe-linux-x86_64.zip`
- `LABEL languages="..."` and the custom-section example use `linux-amd64`

3. Batch JobDefinition implicitly pins X86_64. [lib/infrastructure-stack.ts](https://github.com/aws-samples/aws-transform-custom-samples/blob/atx-remote-infra/lib/infrastructure-stack.ts) creates a Fargate `CfnJobDefinition` with `platformCapabilities: ['FARGATE']` and no `runtimePlatform` block, so it defaults to `X86_64/LINUX`. ARM Fargate requires an explicit `runtimePlatform: { cpuArchitecture: 'ARM64' }`.

### Use Case

`AWS/early-access-java-x86-to-graviton` jobs run remotely will produce transformed code, but the post-transform build/test steps execute on x86, so the migration's actual goal - confirming the artifact runs on Graviton - can't be validated in remote mode.
Local mode on a user's Apple Silicon / Graviton dev machine works for verification today, but doesn't scale.

### Proposed Solution

1. Publish an ARM64 image to `public.ecr.aws/d9h8z6l7/aws-transform` - either a multi-arch manifest list at `:latest`, or a separate tag (`:latest-arm64`).
2. Parameterize the `runtimePlatform` on the Batch JobDefinition via a new `cdk.json` context key (e.g. `cpuArchitecture: "X86_64" | "ARM64"`).
3. Make the Dockerfile arch-aware (`TARGETARCH`) so `JAVA_HOME` path, AWS CLI URL, and labels resolve correctly under both `--platform=linux/amd64` and `--platform=linux/arm64`.
4. Optionally accept a per-job `architecture` field on the Lambda payload so users can mix x86 and ARM jobs against the same infra.

Happy to take a stab at a PR if useful - want to confirm direction first.

### Other Information

_No response_

### Acknowledgements

- [x] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

Start with cdk.json, container/Dockerfile, and lib/infrastructure-stack.ts; inspect how the image is built or published and how the Batch CfnJobDefinition receives its architecture. Confirm the chosen x86_64/ARM64 configuration and image-tag strategy, then verify remote transformation build and test jobs run on the intended architecture for both supported modes.

Written by the indexing model from the issue text.