Minimal remote run control after run lifecycle

[stainlu]

now that the v1 run lifecycle exists (runId, run_start / run_end, run replay, run stream), i think the next control surface can stay very small.

not a full admin API / dashboard / registry yet. just one primitive:

POST /agents/:name/:id/runs/:runId/abort

rough shape:

• best-effort abort for an active run
• uses the same underlying abort path as local CallHandle.abort() where possible
• returns 202 when cancellation is requested
• returns a clear 404 / 409 when the run is unknown, already terminal, or not abortable
• emits the normal terminal lifecycle event: run_end { runId, status: "cancelled" }
• existing /runs/:runId/stream should then show the cancellation through the same event path

what i would not include in v1:

• pause/resume
• dashboard/admin routes
• run listing / registry semantics beyond what already exists
• operation-level control unless the run-level shape proves too coarse

main question: should this abort the whole run, or should Flue expose operation-level abort first now that operationId exists too?

my instinct: run-level first, because it maps cleanly to the remote observable thing from #91. operation-level control can follow once there is a concrete case where aborting the whole HTTP invocation is too broad.