Create a CRUD API for Workers

[sfunkenhauser]

Add a CRUD API for workers. This is a pre-requisite to #729.

[troychiu]

Hi sfunkenhauser I can help with this one

[sfunkenhauser]

I've already started working on this, so let me keep it.

[troychiu]

Sounds good. Thanks for letting me know. I can help with #729, if you'd like.

[AiWatson343]

Adding a CRUD API for workers seems like the right foundation for #729. Having a first-class worker resource API will make worker lifecycle management explicit instead of relying on implicit synchronization paths.

A few things worth considering as part of the design:

Define the worker resource model clearly (identity, status, capabilities, runtime/sandbox class, pool membership, health, and lifecycle state).

Keep create/update/delete semantics aligned with the eventual controller reconciliation model so API operations represent desired state rather than directly mutating runtime state.

Include status reporting separately from spec fields to avoid mixing user intent with observed worker conditions.

Consider idempotency and concurrency handling, since worker state may also be updated by the WorkerPoolSyncer/controller.

This should provide a clean API boundary for #729 and make future worker orchestration features easier to build.