[scs2] Diskless flavors in multi-AZ clouds failure

/kind bug

What steps did you take and what happened:
I created a multi-worker cluster where I used worker nodes with diskless flavors (e.g. workerFlavor=SCS-2V-4) and thus a non-zero volume size for the worker (workerRootDisk=50).
This ended up with one worker node failing:

│ fault                                ┆ {"code":500,"created":"2026-04-24T12:54:49Z","details":null,"message":"Build of instance      │
│                                      ┆ a53e579b-b653-44e4-ad0e-973c118a61e3 aborted: Invalid volume: Instance                        │
│                                      ┆ a53e579b-b653-44e4-ad0e-973c118a61e3 and volume 24769d3f-c4e7-4c24-b033-a0563fe4768a are not  │
│                                      ┆ in the same availability_zone. Instance is in nbg6. Volume is in nbg1"}                       │
│ status                               ┆ ERROR                                                                                         │

The error message is clear. When I create a VM with a diskless flavor, someone (capo in this case) needs to create a bootable volume from the image and then boot from it. In many clouds, cross-az volume attachment is disallowed. (In those clouds where it is allowed, it's still a bad idea for performance reasons -- except if your storage is global, of course.)

No explicit availability zone (failure domain) was passed to capo, so we left it to the system to determine this ... without luck.

What did you expect to happen:
openstack server create --block-device boot_index=0,source_type=image,uuid=$IMGID,destination_type=volume,volume_size=50,delete_on_termination=true ... always works, because the nova scheduler picks a host first and then passes the availability zone from that host to cinder for volume creation and insists on it iif cross-attachment is not enabled. (This works only if storage and compute AZs have a 1:1 mapping with identical names, which is the case on sane clouds.)
I expected capo to take care of this.

Anything else you would like to add:
I could work around using diskful flavors.
Or I could explicitly force an availability zone on my workers (machine deployement), yet I have to work this into the automation to be able to pass it down.

However, I would expect for capo to be more clever here and do as nova does: get a AZ from the nova scheduler and then pass it to conder for the volume creation.

Environment:

• noris Sovereign Cloud (three AZs for compute and for volumes)
• ClusterStack openstack-scs2-1-34-v0-git-8271ca4 with kubernetes-v1.34.7
• scs-training-kaas-scripts for management

Start by tracing how CAPO handles diskless flavors and creates bootable volumes for worker machines, focusing on availability-zone selection between Nova and Cinder. Reproduce the multi-AZ case with workerFlavor=SCS-2V-4 and workerRootDisk=50; done means the volume is created in the instance's zone and the worker boots successfully.