feat(management): show only own rows on Clusters / Storage Types lists

The two management pages now pass ``mine=true`` to their list APIs.
With multi-tenant cluster_access in place an Org Owner would
otherwise see rows that came in via cross-Org grants — usable but
read-only — and editing/deleting them would 403 from the backend.
Restricting the management lists to rows the caller's scope owns
keeps the UX honest. PV-create / GPU-instance-create pickers still
query without ``mine`` so usable cross-Org clusters and types are
selectable there.

src/pages/cluster-management/clusters.tsx

@@ -73,7 +73,14 @@ const Clusters: React.FC = () => {
     deleteAPI: deleteCluster,
     watch: true,
     API: CLUSTERS_API,
-    contentForDelete: 'menu.clusterManagement.clusters'
+    contentForDelete: 'menu.clusterManagement.clusters',
+    defaultQueryParams: {
+      // Management view: drop cross-Org cluster_access grants. Org
+      // Owner only sees the clusters they own here. Pickers that
+      // need "everything I can use" (GPU-instance create, etc.)
+      // query without ``mine`` and still see granted clusters.
+      mine: true
+    }
   });
   const navigate = useNavigate();
   const { goToGrafana, ActionButton } = useGranfanaLink({

src/pages/gpu-service/storage-types/index.tsx

@@ -42,7 +42,13 @@ const GPUServiceStorageTypes: React.FC = () => {
     watch: false,
     polling: false,
     API: GPU_SERVICE_STORAGE_TYPE_API,
-    contentForDelete: intl.formatMessage({ id: 'gpuservice.storageType' })
+    contentForDelete: intl.formatMessage({ id: 'gpuservice.storageType' }),
+    defaultQueryParams: {
+      // Management view: drop types reachable only via cross-Org
+      // cluster_access. The PV-create picker queries without ``mine``
+      // and still sees those for use.
+      mine: true
+    }
   });
 
   const { fetchData: createStorageType } = useCreateStorageType();