Track Apple container runtime support gaps

## Summary

Track remaining gaps for supporting Apple `container` as a DCP container runtime, measured against the capabilities DCP currently uses from Docker and Podman.

## Blocking gaps

- [ ] **Tar/archive-based copy into containers**
- https://github.com/apple/container/issues/1908
- Apple `container cp` is path-based only.
- It does not accept `-`/stdin tar streams.
- It does not expand tar archives into the container filesystem.
- Copy-in appears to require the container to be running.
- DCP impact: blocks `CreateFiles`, which streams generated tar contents into a created container before start.

- [ ] **Network aliases**
- https://github.com/apple/container/issues/1839
- Apple `--network` supports network name plus options like `mac` and `mtu`, but not Docker/Podman-equivalent aliases.
- DCP impact: blocks Docker/Podman-style service discovery if DCP network aliases are required.

- [ ] **Container-to-container DNS parity**
- https://github.com/apple/container/issues/1809
- Apple has container DNS lookup support, but it appears oriented around container hostnames/IDs/FQDNs rather than arbitrary network aliases.
- DCP impact: limits service discovery unless DCP can avoid alias-based names for this runtime.

## Gaps requiring workarounds or degraded functionality

- [ ] **Runtime events/watch support**
- https://github.com/apple/container/issues/484
- No Docker/Podman-style `events` command or equivalent watch API was identified.
- DCP impact: container/network watches would require polling or another Apple-specific strategy.

- [ ] **Stable host callback name**
- https://github.com/apple/container/issues/673
- No obvious equivalent to Docker `host.docker.internal` or Podman `host.containers.internal` was identified.
- DCP impact: may affect `ContainerHost()` and host callback/proxy paths that need a stable host name from inside containers.

- [ ] **Pull policy semantics during create/run**
- Apple fetch behavior appears to use a local image if present and pull if missing.
- No clear equivalent to Docker/Podman `--pull=always`, `--pull=never`, or `--pull=missing` on create/run was identified.
- DCP impact: may affect `PullPolicyAlways` / `PullPolicyNever` semantics.

- [ ] **Inspect/status fidelity**
- https://github.com/apple/container/issues/1501
- Apple status appears coarser than Docker/Podman, e.g. `unknown`, `stopped`, `running`, `stopping`.
- DCP impact: may limit reporting or controller behavior that depends on created/exited/dead states, exit code, finished time, health, or error details.

- [ ] **Log timestamps**
- https://github.com/apple/container/issues/1591
- `container logs` supports basic log retrieval/following, but no timestamp option was identified.
- DCP impact: `StreamContainerLogsOptions.Timestamps` may not be implementable exactly.

## Honorable mentions

- [ ] **Forced volume removal**
- Apple volume delete rejects in-use volumes and no force option was identified.
- DCP impact: mostly affects order of operations. This should be fine if DCP removes containers before volumes, but it remains a parity difference for `RemoveVolumesOptions.Force`.

- [ ] **Build image ID file output**
- Apple build does not appear to have a Docker/Podman `--iidfile` equivalent.
- DCP impact: likely none today. `BuildImageOptions.IidFile` still exists and Docker/Podman still support it, but current DCP build callers do not appear to set it.

- [ ] **Healthcheck configuration/status**
- https://github.com/apple/container/issues/1918
- No Docker/Podman-style healthcheck configuration or health status equivalent was identified.

No file or test is named. Start by tracing the DCP entry points called out here—CreateFiles, ContainerHost, PullPolicyAlways/PullPolicyNever, StreamContainerLogsOptions.Timestamps, and status handling—and compare their Docker/Podman behavior with Apple container. Done would require selecting and implementing a specific runtime gap, or documenting a confirmed workaround or limitation.

Written by the indexing model from the issue text.