Function worker_artifact 

pub async fn worker_artifact(
    __arg0: State<AppState>,
    headers: HeaderMap,
    __arg2: Query<ArtifactQuery>,
    body: Bytes,
) -> Result<StatusCode, ApiError>

POST /v1/worker/artifact?name=<name>. Bearer = same short-handle / full-CapToken forms as worker_submit. Body = raw text/octet.

Simplification-axis sibling of worker_submit (GH #36 ST1): lets a worker with more than one named result POST each part independently — same 1-part-per-POST simplicity as /v1/worker/submit, no Single Big JSON the worker has to construct/escape itself — then complete the attempt with an ordinary /v1/worker/submit (unchanged). Staging alone never completes the attempt; dispatch_attempt_with only pulls the tail’s Final (whichever endpoint submits it) and folds every staged Artifact into "parts" at that point.

Behavior:

• task_id is auto-looked-up server-side from the token/handle, same as worker_submit.
• name is required and non-empty; missing or blank → 400.
• Body raw bytes go as-is into Value::String (same trailing-whitespace trim as worker_submit) and are staged via mlua_swarm::core::engine::Engine::stage_worker_artifact_trusted — which is also what materialize_part writes, so the part FILE is always the submitted bytes verbatim. The engine’s Final-pull fold applies its default lenient container parse to the part’s ctx value (a JSON object / array part becomes addressable, e.g. $.<step>.parts["plan-meta.json"].lanes); submit_format: "text" on the step opts its parts (and body) out of that parse.
• Staging the same name twice within one attempt: last write wins (the Final-pull fold walks the tail in event order — see its doc).