Make fresh zonal claims fit their consumer during maintenance

Edit zonal.yaml as a creation proposal: one StorageClass, data/logs PVCs and loader Pod. Each test starts with fresh claims; maintenance is a separate cold start, not relocation of bound data. Preserve analytics/loader, container loader, image analytics-loader:3 and writable /data→data, /logs→logs mounts. Claims need Filesystem, ReadWriteOnce and at least data=40Gi, logs=10Gi; reference your class explicitly. The observed driver zonal.csi.example supports only ReadWriteOnce/Filesystem and WFFC. Pod requests must reserve at least CPU=2, memory=6Gi; limits supply a missing request but do not replace an explicit smaller request. Approved nodes/zones are north-worker/north and south-worker/south. All nodes have CPU=4. Normal residual memory is north=8Gi, south=4Gi; maintenance cordons north and gives south=8Gi. Both are Ready and untainted. external-worker/external has 32Gi but is forbidden. Labels: topology.kubernetes.io/zone=zone; storage-pool=approved on north/south, external elsewhere. Each trial has shared storage pools north=60Gi, south=50Gi, external=100Gi; every pool has maximum volume size=45Gi and those same labels. Both claims must provision in the consumer's zone. This supplied Immediate provisioner allocates data then logs, trying north, south, external before seeing a Pod; WFFC uses a scheduler-eligible consumer zone. nodeName bypasses that scheduler and leaves WFFC claims pending. Restrict Pod placement and allowedTopologies to approved inventory; list terms OR, expressions within a term AND. Establish joint compute and shared storage fit in both trials. Run tests, inspect eligible nodes/claim-zone witnesses and repair without Reset.