CreateSharedFileSystem NPE ("template is null") when zone has mixed hypervisor types

## Bug: `CreateSharedFileSystem` throws NPE ("template is null") when a zone has more than one hypervisor type

**Component:** `plugins/storage/sharedfs/storagevm/src/main/java/org/apache/cloudstack/storage/sharedfs/lifecycle/StorageVmSharedFSLifeCycle.java`
**Affected versions:** 4.22.1.0 (confirmed present on `main` as of 2026-08-06 — same code, unrelated to the two unrelated API-signature diffs between `main` and `4.22.1.0` in this file)

### Summary

`createSharedFileSystem` fails immediately with:

```
java.lang.NullPointerException: Cannot invoke "com.cloud.storage.VMTemplateVO.getId()" because "template" is null
```

on any zone that has **more than one hypervisor type**, where at least one of those hypervisor types has no system VM template available (e.g. an `External`/MaaS cluster alongside a `KVM` cluster in the same zone).

### Root cause

In `deploySharedFSVM()`:

```java
List hypervisors = resourceMgr.getSupportedHypervisorTypes(zoneId, false, null);
if (hypervisors.size() > 0) {
Collections.shuffle(hypervisors);
} ...

for (final Iterator iter = hypervisors.iterator(); iter.hasNext();) {
final Hypervisor.HypervisorType hypervisor = iter.next();
VMTemplateVO template = templateDao.findSystemVMReadyTemplate(zoneId, hypervisor, preferredArchitecture);
if (template == null && !iter.hasNext()) {
throw new CloudRuntimeException(...);
}
LaunchPermissionVO existingPermission = launchPermissionDao.findByTemplateAndAccount(template.getId(), owner.getId());
...
```

The hypervisor list is **shuffled**, and the null-check only throws when the *current* hypervisor is the *last* one in the iteration (`!iter.hasNext()`). If `template` is `null` for a hypervisor that is **not** last in the (randomized) order — e.g. `External`, which has no CloudStack system VM template by design — the code falls through to `template.getId()` on the same iteration instead of `continue`-ing to the next hypervisor. This crashes before ever reaching a hypervisor (e.g. `KVM`) that does have a valid, `Ready` system VM template.

Because the list is shuffled, this is intermittent: the call succeeds whenever the working hypervisor happens to be drawn first, and fails whenever a hypervisor with no system VM template is drawn first with more entries still pending.

### Reproduction

1. Zone with two clusters of different hypervisor types, one of which has no system VM template registered (e.g. `KVM` + `External`/MaaS).
2. Call `createSharedFileSystem` repeatedly.
3. Observe intermittent NPE vs. success depending on shuffle order, even though the working hypervisor's system VM template is verified `Active` / `Ready` / fully downloaded in the DB (`vm_template`, `template_zone_ref`, `template_store_ref`).

### Impact

Any deployment mixing hypervisor types within one zone (common with hybrid KVM + MaaS/External or KVM + VMware setups) can hit this nondeterministically for every Shared FileSystem creation attempt, with no workaround short of isolating hypervisor types into separate zones.

Commencez par examiner la pull request fusionnée #13830, puis inspectez deploySharedFSVM dans plugins/storage/sharedfs/storagevm/src/main/java/org/apache/cloudstack/storage/sharedfs/lifecycle/StorageVmSharedFSLifeCycle.java. Reproduisez createSharedFileSystem avec des types d’hyperviseur mixtes et vérifiez que l’absence d’un template ne provoque plus de NPE et qu’un template de system VM valide peut être sélectionné.

Rédigé par le modèle d'indexation à partir du texte de l'issue.