fix(load_artifact): load urls into the named container, not the sandbox's agent container

[earakely-scale]

What and why

A load_artifact step with sandbox_name and container_name targets a container that run_docker_container started on a VM sandbox. Artifacts loaded that way reach the container: a universe or environment payload is staged on the VM host and copied in. URLs did not.

The URL branch called sandbox.write_file_from_url(url, dest). That method downloads onto the VM host and copies into the sandbox's own agent container (agent-api on remote VMs, agent-<id> locally), not the named container. So the files landed in the wrong container, and on a sandbox with no agent the copy failed with "No such container".

Now, with container_name set, each URL is downloaded onto the VM host and copied into that container at destination_path/<name>, the way the universe path already works. The temp file on the host is removed either way. Steps without container_name are unchanged.

How it was tested

• make unit-test: 6792 passed. A new unit test checks that a URL with container_name is copied into that container, and never through write_file_from_url.
• A new local integration test runs run_docker_container, then load_artifact with urls and container_name, then reads the file back from inside the step container. It passes on macOS.
• check_plugin_api.py: no break to the plugin surface.

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge; no new actionable issue or outstanding numbered finding remains.

Summary

URL downloads for load_artifact steps now reach the named container on VM sandboxes, instead of the sandbox’s agent container.

• URL files now reach the named container on VM sandboxes.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  URL[URL] --> VM[Temporary file on VM host]
  VM --> Container[Named Docker container]
  VM --> Cleanup[Remove temporary file]

Loading

_{Reviews (3) · Last reviewed commit: "fix(load_artifact): a cancelled url load..." · Reviewed by Greptile}

[earakely-scale]

Chaos run: local on macOS (Rancher Desktop) and native Linux (Docker 29, x86); remote on modal_vm.

Scenario	macOS	Linux
URL returns 404	fails with curl's 404	same
Host unreachable	fails with curl's connect error	same
Step container removed before the load	fails: "No such container: worker-…"	same
Non-root container, destination folder doesn't exist yet	file lands, readable by the user	same
10 URLs at once: named, bare (repeat suffixed), names with spaces	each under its own name	same
300 MiB file	same bytes in the container (1.5 s)	same (1.1 s)
Two runs, same container_name	each run's file only in its own container	same
Cancelled mid-download	staged file removed	same
An agent on the same sandbox	file in the step container, not the agent's	same

Every scenario left no container and no staged /tmp/_load_url_* file.

Remote (modal_vm), with an agent on the same VM:

• a named and a bare URL landed in the step container and not in agent-api;
• a 404 failed with curl's error;
• nothing was left staged on the VM.

Separately: a .zip docker_context_url fails on modal_vm because the VM has no unzip. That's unrelated to this PR and tracked separately.