feat(controller): change replicas through the scale subresource

[slauger]

Summary

A full-object update is the wrong tool for a replica change on a workload that something else also manages. A HorizontalPodAutoscaler writes through /scale, so a narrow write competes with it cleanly, whereas a full-object update replays the entire spec on a conflict retry.

Deployment and StatefulSet now change replicas through client.SubResource("scale"). CronJob is unchanged: it has no scale subresource, and spec.suspend remains the mechanism.

The two branches were near-identical, so they collapse into one helper.

The write order is deliberate and is the part worth reviewing. Annotations are written first, then the scale call. If the scale fails, the workload is still running and the next evaluation retries it, so the state corrects itself. In the other order, a failed annotation write would leave a workload stopped with no record of its previous replica count, and the zero-replica guard at the top would stop the operator ever revisiting it, making the loss permanent. There is a test for this with an injected scale failure.

RBAC gains deployments/scale and statefulsets/scale with get and update. Narrow and explicit; make check-rbac confirms the chart and the markers agree.

The generic "any kind implementing /scale" variant remains rejected, with the three blockers recorded on #68 so the question is not reopened without them.

Closes #68

Test plan

• make ci passes; existing scale-down tests continue to assert replicas == 0, so the subresource path is genuinely exercised rather than silently skipped.
• New test injects a failing scale subresource and asserts the workload is left running and the previous replica count was already recorded. That test fails if the order is swapped.
• New tests for an already-stopped workload, which must write no annotations at all, and for dry run, which must touch neither replicas nor annotations.
• Coverage 64.1 percent.