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.

Start by reviewing the merged pull request #13830, then inspect deploySharedFSVM in plugins/storage/sharedfs/storagevm/src/main/java/org/apache/cloudstack/storage/sharedfs/lifecycle/StorageVmSharedFSLifeCycle.java. Reproduce createSharedFileSystem with mixed hypervisor types and verify that a missing template no longer causes an NPE and a valid system VM template can be selected.

Written by the indexing model from the issue text.