CKS lifecycle fails on VPC tier without an attached network ACL

##### ISSUE TYPE
* Bug Report

##### COMPONENT NAME
~~~
Kubernetes Service (CKS), VPC, Network ACL
~~~

##### CLOUDSTACK VERSION
~~~
4.22.1.0
main (reproduced by regression test at 4f117071c9397b1e4714c8fb61c384883c872842)
~~~

##### CONFIGURATION
Advanced zone with NSX-backed networking, VPC with an ACL-capable tier offering, and a CKS cluster deployed within a project.

The live reproduction used the NSX VPC offering `VPC offering with NSX - NAT Mode` and the tier offering `DefaultNSXVPCNetworkOfferingforKubernetesService`. The tier offering includes the NetworkACL service with provider Nsx.

##### OS / ENVIRONMENT
Management server on Debian 13, VMware vSphere hypervisor, NSX 4.2.4, NFS primary/secondary storage, and CKS Kubernetes v1.34.7.

##### SUMMARY
CKS create, etcd setup, validation, and delete paths throw an unboxing `NullPointerException` when a VPC tier does not yet have a network ACL attached.

A missing tier ACL is a supported CloudStack state, not an invalid database artifact:

- `createNetwork` declares `aclid` as optional.
- CloudStack deliberately stopped assigning default-deny unconditionally in CLOUDSTACK-2809 (`b5148af0c6dfc583bcd1a52a7510df80e9eaa163`).
- `NetworkACLServiceImpl.createAclListIfNeeded` explicitly preserves the legacy behavior of creating and attaching a custom ACL when a rule is created with `networkid` but no `aclid`.
- `NetworkACLItemDaoImpl.listByACL(null)` intentionally returns an empty list.

CKS already supplies `networkid` when provisioning a VPC-tier ACL rule, so it should reach that existing auto-create path. Instead, four comparisons auto-unbox the nullable `Long` returned by `Network.getNetworkACLId()` against primitive `long` constants:

- `KubernetesClusterManagerImpl.validateVpcTier`
- `KubernetesClusterResourceModifierActionWorker.createVpcTierAclRules`
- `KubernetesClusterResourceModifierActionWorker.removeVpcTierAclRules`
- `KubernetesClusterStartWorker.setupKubernetesEtcdNetworkRules`

This is present in 4.22.1.0, current `4.22`, and current `main`.

On an unmodified current-main checkout, focused regression tests covering these four nullable-ACL paths produced four errors with the same `Long.longValue()` NPE while all 56 existing/control tests passed.

##### STEPS TO REPRODUCE
~~~
1. Create a VPC with an offering compatible with the chosen ACL-capable tier offering.
2. Create the tier through the API without aclid:

cmk create network \
name=cks-null-acl-tier \
displaytext=cks-null-acl-tier \
networkofferingid= \
vpcid= \
zoneid= \
gateway=10.35.15.1 \
netmask=255.255.255.0

3. Confirm that listNetworks reports no aclid for the tier.
4. Create a CKS cluster on that tier.
5. After the create failure, stop and start the cluster, then attempt to delete it.
~~~

No database changes were used to create the failing state. The only omitted input was the optional `aclid`.

In the live 4.22.1.0 reproduction, all cluster VMs were provisioned before create failed in `createVpcTierAclRules`. The cluster remained in `Starting` with an empty endpoint. Stop succeeded, start then failed because the endpoint was never recorded, and delete failed in `removeVpcTierAclRules`.

Attaching an ACL with `replaceNetworkACLList` allowed cleanup to complete.

##### EXPECTED RESULTS
~~~
- A CKS cluster can use an ACL-capable VPC tier whose ACL has not yet been attached.
- CKS reaches the existing NetworkACLService behavior that creates and attaches a custom ACL when the first rule is added.
- Validation does not reject or NPE on a null ACL ID.
- Deleting a cluster from a tier that still has no ACL treats ACL cleanup as a no-op.
~~~

##### ACTUAL RESULTS
~~~
Create:

java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()"
because the return value of "com.cloud.network.Network.getNetworkACLId()" is null
at com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterResourceModifierActionWorker.createVpcTierAclRules(KubernetesClusterResourceModifierActionWorker.java:720)
at com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterResourceModifierActionWorker.setupKubernetesClusterVpcTierRules(KubernetesClusterResourceModifierActionWorker.java:774)
at com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterStartWorker.setupKubernetesClusterNetworkRules(KubernetesClusterStartWorker.java:624)
at com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterStartWorker.startKubernetesClusterOnCreate(KubernetesClusterStartWorker.java:821)
at com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.startKubernetesCluster(KubernetesClusterManagerImpl.java:1865)

Delete:

java.lang.NullPointerException: Cannot invoke "java.lang.Long.longValue()"
because the return value of "com.cloud.network.Network.getNetworkACLId()" is null
at com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterResourceModifierActionWorker.removeVpcTierAclRules(KubernetesClusterResourceModifierActionWorker.java:749)
at com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterDestroyWorker.deleteKubernetesClusterVpcTierRules(KubernetesClusterDestroyWorker.java:197)
at com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterDestroyWorker.deleteKubernetesClusterNetworkRules(KubernetesClusterDestroyWorker.java:215)
at com.cloud.kubernetes.cluster.actionworkers.KubernetesClusterDestroyWorker.destroy(KubernetesClusterDestroyWorker.java:326)
at com.cloud.kubernetes.cluster.KubernetesClusterManagerImpl.destroyKubernetesCluster(KubernetesClusterManagerImpl.java:2439)
~~~

まず KubernetesClusterManagerImpl.validateVpcTier と KubernetesClusterResourceModifierActionWorker.createVpcTierAclRules/removeVpcTierAclRules の nullable な ACL 比較から始め、次に KubernetesClusterStartWorker.setupKubernetesEtcdNetworkRules を調査します。これら 4 つのパスを対象とするフォーカスされた回帰テストを実行します。完了の条件は、ACL が関連付けられていない VPC tier が、検証、作成、開始、削除の際に NPEs を発生させなくなり、既存の ACL の自動作成およびクリーンアップの動作が維持されることです。

索引モデルが issue の本文から書いたものです。