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 中可为 null 的 ACL 比较开始，然后检查 KubernetesClusterStartWorker.setupKubernetesEtcdNetworkRules。运行覆盖这四条路径的针对性回归测试。当没有关联 ACL 的 VPC tier 在验证、创建、启动或删除期间不再导致 NPEs，并且现有的 ACL 自动创建和清理行为保持不变时，即表示完成。

由索引模型根据 Issue 内容生成。