fix(harness): build and push harness Dockerfile via CDK asset (#927)

[aryankhanna2004]

Summary

Fixes #927. When a harness's harness.json sets dockerfile instead of containerUri, the deploy pipeline previously dropped the field silently: the CDK stack produced no image asset and the mapper omitted environmentArtifact from CreateHarness, so the harness came up without the user's custom container.

This wires the dockerfile through end-to-end:

• src/assets/cdk/bin/cdk.ts — forwards dockerfile and a resolved codeLocation (absolute harness directory) into the stack props.
• src/assets/cdk/lib/cdk-stack.ts — creates a linux/arm64 DockerImageAsset per harness that specifies a dockerfile, and emits its imageUri as a per-harness CfnOutput named ApplicationHarness<Pascal>ImageUri.
• src/cli/operations/deploy/imperative/deployers/harness-mapper.ts — resolves that output from cdkOutputs and populates environmentArtifact.containerConfiguration.containerUri on CreateHarness. If the expected output is missing (e.g. Docker was unavailable during synth), the mapper now throws an actionable error instead of continuing silently.

Behavior preserved when neither dockerfile nor containerUri is set (harness uses the managed default image). Explicit containerUri still takes precedence over a built image.

A Docker daemon with buildx linux/arm64 support is required at agentcore deploy time, matching the existing requirement for agent runtime Dockerfiles.

Test plan

• npm run typecheck clean
• npm run lint — 0 errors (all remaining warnings are pre-existing)
• 3 new unit tests in harness-mapper.test.ts:
  • resolves built image URI from CDK outputs when dockerfile is set
  • throws actionable error when output is missing
  • explicit containerUri still wins over built image
• Asset snapshot tests updated (npm run test:update-snapshots for the affected CDK files)
• End-to-end against a real project (harness with dockerfile: "Dockerfile", AWS_IAM auth, Claude Opus, browser + code interpreter, PPTX skill):
  • arm64 image built locally and pushed to cdk-hnb659fds-container-assets-<acct>-us-east-1
  • Stack output ApplicationHarnessPptagentImageUri emitted
  • CreateHarness accepted the environmentArtifact; harness reached READY

Fixes #927

[aryankhanna2004]

Closing in favor of #929 (by @tejaskash), which landed a few minutes before this one and takes a cleaner approach.

tl;dr: #929 reuses the existing agent Container build pipeline in the CLI (ContainerSourceAssetFromPath + AgentEcrRepository + ContainerBuildProject + ContainerImageBuilder from @aws/agentcore-cdk), so the build runs in AWS CodeBuild with native arm64 and no local Docker daemon required. This PR used DockerImageAsset from aws-cdk-lib/aws-ecr-assets, which forces every user to have a local docker buildx with arm64 emulation and introduces a second build primitive alongside the one agents already use.

Full comparison and rationale in #927 (comment).

No action items for reviewers here — please move discussion to #929.