Let callers choose the image platform in ContainerManager.create

[rcfa]

Summary

ContainerManager.create resolves images against .current, so a container can only be created
from an image variant matching the host architecture. This adds an optional platform parameter
(defaulting to .current) so callers can select a different variant.

The problem

Two sites on the create path pin the platform:

// Sources/Containerization/ContainerManager.swift
let imageConfig = try await image.config(for: .current).config           // :295
return try await unpacker.unpack(image, for: .current, at: destination)  // :346

Creating a container from an amd64 image on an arm64 host fails with:

platform linux/arm64

Two things make this hard to diagnose from the outside:

1. The error names the platform that was requested, not the one the image has, so it looks
   like the image is mistagged or corrupt.
2. It happens with rosetta: true on the ContainerManager as well — the failure is at config
   resolution, before the runtime reaches the point where translation applies. So the flag that
   exists to make this case work appears to do nothing, with no indication why.

The change

Image.config(for:) and EXT4Unpacker.unpack(_:for:at:progress:) already accept a platform; only
create pins it. This threads platform: Platform = .current through the three create overloads
and the private unpack.

The default preserves current behaviour exactly — the change is additive, and no existing caller
needs to change.

Why it matters in practice

We run SWE-bench's per-instance task images on Apple silicon. That corpus is mixed: of the 500
SWE-bench Verified instances, 281 publish arm64 images and 219 publish amd64 only. A host-pinned
platform therefore makes 44% of the benchmark unrunnable — and evaluating only the arm64 remainder
would produce a score over a non-random subset (architecture correlates with repository and era),
which would not be a valid benchmark result.

Verification

Tested on an arm64 host against both variants, running the same command shape in each:

image	result
astropy instance (arm64)	conda env activates; import astropy → 5.1.dev623+gd16bfe05a7
pytest instance (amd64, Rosetta)	uname -m → x86_64; import _pytest → 3.9.20

The second row is the case that could not be expressed before this change.