Describe the bug

AddDockerfile (and related overloads) attaches a ContainerBuildOptionsCallbackAnnotation that defaults TargetPlatform to ContainerTargetPlatform.LinuxAmd64. The publishing path (DockerContainerRuntime.RunDockerBuildAsync / PodmanContainerRuntime) reads this annotation and passes --platform linux/amd64 to the runtime build command.

The local dev path, however, goes through DCP via ContainerCreator.ApplyBuildArgumentsAsync, which never reads the annotation. As a result, docker build is invoked without --platform and defaults to the host architecture.

Expected Behavior

The DCP build path should pass the resource's resolved TargetPlatform to the runtime, matching the publishing path's behavior.

Steps To Reproduce

1. On an arm64 host (e.g. Apple Silicon), create an AppHost with builder.AddDockerfile("myapp", "context-path", "Dockerfile").
2. Have the Dockerfile install or copy x86_64-only binaries (anything that fails to run under linux/arm64).
3. dotnet run the AppHost.
4. The build runs as linux/arm64 and fails, even though the resource's resolved TargetPlatform is LinuxAmd64.

Actual

No --platform flag is sent. The DCP BuildContext model has no Platform field, even though the DCP runtime already supports a json:"platform" field on the build spec.

Anything else?

• Aspire main (reproduced against 13.4.0-dev build of the repo)
• macOS, arm64
• Docker Desktop

Happy to send a PR — the change is small (add Platform to BuildContext, populate it from ProcessContainerBuildOptionsCallbackAsync in ApplyBuildArgumentsAsync).