Cluster API provider: implement conflict-safe `AtomicIncreaseSize`

Which component are you using?:

Cluster Autoscaler

/area cluster-autoscaler

Is your feature request designed to solve a problem? If so describe the problem this feature should solve.:

The Cluster API cloud provider currently returns cloudprovider.ErrNotImplemented from AtomicIncreaseSize. As a result, the best-effort-atomic-scale-up.autoscaling.x-k8s.io ProvisioningRequest path falls back to the normal IncreaseSize implementation.

The normal CAPI implementation reads the current replica count and then applies the desired count using a merge patch. A concurrent writer can modify the scalable resource between these operations, causing the patch to overwrite the newer replica count. This weakens the all-or-nothing semantics expected by the ProvisioningRequest atomic scale-up path.

Describe the solution you'd like.:

Implement AtomicIncreaseSize for CAPI MachineSets, MachineDeployments, and MachinePools by:

1. Reading the current Scale subresource.
2. Validating that the delta is positive and does not exceed the node group's maximum size.
3. Updating the desired replica count through the Scale subresource while retaining the fetched resourceVersion.
4. Returning conflicts to the caller instead of retrying and potentially overwriting another replica writer.
5. Updating the provider's local target-size snapshot only after the API update succeeds.

This defines atomicity at the CAPI desired-replica mutation boundary: the requested delta is either accepted or rejected as a single optimistic-concurrency update. It intentionally does not wait for Machines or Nodes to become Ready, which matches the NodeGroup.AtomicIncreaseSize interface contract.

Describe any alternative solutions you've considered.:

• Delegate AtomicIncreaseSize to IncreaseSize. This is effectively the same behavior as the existing core fallback and does not prevent lost updates.
• Wait for all Machines or Nodes to become Ready. This would change the AtomicIncreaseSize contract and conflate an accepted capacity request with eventual infrastructure readiness.
• Use provider-specific infrastructure APIs. This would break Cluster API's provider-neutral abstraction and require separate implementations for each infrastructure provider.

Additional context.:

• ProvisioningRequest proposal: https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/proposals/provisioning-request.md
• I haven't found an existing issue or PR specifically implementing CAPI AtomicIncreaseSize.