nas-economy: Clone unpublish breaks source volume NFS access

[clementnuss]

Describe the bug
When a read-only clone volume is deleted on the same node as its source volume, the unpublish operation incorrectly removes export policy rules that are still needed by the source volume. This causes the source volume to lose NFS access with "Stale file handle" errors.

Root Cause
Read-only clones in the nas-economy (qtree) driver don't create new qtrees - they mount the source qtree's .snapshot directory. When a clone unpublishes:

1. The orchestrator checks for remaining publications of only the clone volume
2. Finds none (since the clone is being unpublished)
3. Removes export policy rules for the node
4. The source volume loses access because it shares the same export policy

Environment

• Trident version: 25.06.2
• NetApp backend types: ONTAP nas-economy (qtree) driver
• Storage class: nas-economy with autoExportPolicy enabled
• Other: Using read-only clones with trident.netapp.io/readOnlyClone: "true" annotation

To Reproduce
Steps to reproduce the behavior:

1. Create a source PVC using nas-economy storage class
2. Create a pod mounting the source PVC on node A (pod continues running)
3. Create a VolumeSnapshot from the source PVC
4. Create a read-only clone PVC from the snapshot with annotation trident.netapp.io/readOnlyClone: "true"
5. Create a pod mounting the clone PVC on the same node A
6. Delete the clone pod
7. Observe that the source pod loses NFS access with "ls: can't open '/data': Stale file handle" errors

A reproduction script is available here demonstrating this issue consistently.

Expected behavior
When a read-only clone is deleted, Trident should check for remaining publications of BOTH the clone and the source volume before removing export policy rules. The source volume should maintain NFS access.