feat(eval): run platform tasksets via /rollouts/run_list so traces get task names

[MittelmanDaniel]

Fixes #488

When a platform taskset is run wholesale on HostedRuntime with a stock gateway model, submit the batch as one POST /rollouts/run_list instead of one /rollouts/submit per rollout. The server resolves the task versions itself, so traces come back named and grouped on the dashboard instead of as UUID cards (see the issue for screenshots of the two).

Anything the batch shape can't express falls through to the existing per-rollout path unchanged: an open job, a task subset (which drops api_id), a custom model_client, agent config diverging from the type's defaults, or a model the catalog doesn't know.

Implementation notes:

• HostedRuntime.run_taskset posts once, then polls /jobs/{id}/traces until the caller's tasks×group count is terminal. On timeout or cancel it cancels the submitted traces platform-side. Runs are folded in submission order, deduped against strays, with run.group_id set from each trace's task_version_id so group structure survives. The deviation from Taskset.run's expansion-order promise on this path is documented in its docstring and in the Job.runs reference table.
• _gateway_batch_spec decides expressibility: stock gateway agent whose config matches its type's defaults, model resolved via the catalog (resolve_gateway_model, added to hud/utils/gateway.py). One judgment call: auto_respond is tolerated as a divergence — the CLI's --full always sets it, it only steers the client-side loop, and on this path the platform runs its own loop either way (same as website batch runs). If it should fall back instead, that's a one-line change.
• Extracted the list-envelope parsing that existed twice in cli/jobs.py into hud.utils.platform.list_items and reused it here.

Assumptions worth a look from someone who can see the backend: /jobs/{id}/traces is read as a single unpaginated page; run_timeout bounds the whole batch on this path (fine while traces run concurrently, but different from the per-rollout meaning); and the whole approach leans on run_list accepting API-key auth, so it's worth confirming that's a stable public surface.

Testing: new tests in test_hosted.py (payload shape, polling/folding, ordering/dedup/group_id, scheduler dispatch, fallback for custom agent config); full check suite passes (pytest -q: 682 passed; ruff format --check, ruff check, pyright clean on the touched files). Live A/B on my own taskset: job 8dc2bd52-5621-419b-b6e4-204afb264100 (this branch) has every trace linked to its task version and renders named/grouped; job c0e16e7192af40bbb5305ade930b4434 (stock path, minutes earlier) has task_version_id: null on all traces.

The backend change sketched in #488 (option a) would cover the fallback cases too — this is the client-side half.