Inconsistent StorageClass and AccessMode over cross-StorageClass clone

[zzzanziber]

Describe the bug
When provisioning a volume clone (via dataSource pointing to a PVC or VolumeSnapshot) across different StorageClass and AccessMode that share the same backend, Trident validates and permits the clone operation. However, the resulting internal TridentVolume incorrectly records the source volume's StorageClass and AccessMode instead of the requested target StorageClass.

While the Kubernetes PV and PVC correctly report the target StorageClass and AccessMode, Trident's internal catalog desynchronizes. This results in persistent metadata divergence for storageClass inside Trident and in Kubernetes.

Environment

• Trident version: v25.06.3
• Kubernetes version: 1.32.13
• NetApp backend types: ONTAP SAN

To Reproduce

1. Configure two StorageClass (sc-rwoand sc-rwx) that map to the same NetApp ontap-san backend.
2. Create a source PVC pvc-source with StorageClass sc-rwo and AccessMode ReadWriteOnce.
3. Create a target PVC pvc-clone with StorageClass sc-rwx and AccessMode ReadWriteMany, with a dataSource pointing to pvc-source (or a VolumeSnapshot of pvc-source).
4. Once pvc-clone is bound, inspect the Kubernetes resources and the internal TridentVolume CR.

Expected behavior
The TridentVolume CR for the newly provisioned clone should record .config.storageClass: sc-rwx, matching the target StorageClass requested in the PVC spec.

Additional context
In core/orchestrator_core.go, cross-StorageClass cloning is permitted when the destination StorageClass maps to the source volume's backend.

However, Trident selectively overrides attributes on cloneConfig using the incoming volumeConfig but StorageClass and AccessMode are never updated in this override block. This should be added to fix the inconsistency.