Workload spec changes do not roll running instances #297

Changing a workload's spec does not change what is running. The new spec reaches the WorkloadDeployment, but the existing instance keeps serving the old one, and nothing reports a problem.

A customer who edits a workload has no way to tell their change was ignored. The workload reports Available, the deployment reports 1/1 instances are ready, and the instance reports Ready. The only way to apply a change today is to create a workload under a new name.

What we saw

In the staging datum-cloud project, adding container ports and imagePullSecrets to a running workload updated the WorkloadDeployment template. The instance kept the previous spec and was never replaced. datumctl compute restart did not help: it restarted the container in place, so the workload re-pulled its image with the old spec rather than starting from the new one.

The same spec deployed under a new workload name came up correctly on the first try, which is what isolated this to the update path rather than the spec itself.

Expected

Editing a workload rolls its instances onto the new spec, honouring the placement's instance management policy. If a change cannot be applied, the workload says so rather than reporting healthy.

Why it matters

This affects every field a customer would reasonably change after first deploy: image, ports, pull secrets, environment, and mounted configuration. It also makes restart misleading, since the command implies picking up current state.