multus: resources validation lets zero and mistyped values through #4885

The resources checks added in #4830 let some wrong values through to the cluster. None of them breaks a default install, they all need a deliberate value.

1. A zero memory quantity passes the multus chart guard, because the guard only tests that the value is non-empty. --set resources.limits.memory=0Gi (or "0") renders. With the default 100Mi request the API server then rejects the DaemonSet (request above limit), so the HelmRelease fails on apply. If requests.memory is zero as well, the pod is admitted and runs with no memory.max, which is exactly what the guard is there to prevent. Rejecting a zero quantity on both keys closes it. Review thread: fix(multus): drop the CPU limit and make resources configurable #4830 (comment)
2. resources.limits.memory: {} fails with "must be set", although it is set. The render stops as it should, only the message is wrong. Review thread: fix(multus): drop the CPU limit and make resources configurable #4830 (comment)
3. The platform helper checks only that networking.multus.resources is a map. resources.limits: 4Gi passes there, the platform HelmRelease goes Ready, and the error shows up one object later in the multus HelmRelease. stageCniPlugins is validated in full at the platform, and resources could get the same map checks the multus chart runs. Review thread: fix(multus): drop the CPU limit and make resources configurable #4830 (comment)
4. The comment on cozystack.platform.multus.values says resources is passed only when set, but resources: {} is forwarded too. Harmless, Helm keeps the chart defaults under an empty map, the comment just needs to say "unless unset". Review thread: fix(multus): drop the CPU limit and make resources configurable #4830 (comment)