kafka: the operator JVM test pins env by index, and MaxRAM truncates fractional limits #4882

Two minor leftovers from the Kafka JVM sizing in #4865. Neither breaks anything today.

The cluster operator test in packages/system/kafka-operator/tests/jvm_sizing_test.yaml finds CONTAINER_MEMORY_LIMIT, CONTAINER_CPU_LIMIT and JAVA_OPTS at env[19], env[20] and env[21]. What has to hold is their relative order, because $(VAR) expands only from earlier entries. An env var added upstream shifts the indices, so a Strimzi bump turns the test red with no real defect. Asserting the order of the three names would survive that. #4665 tracks the same kind of position-based selection for whole documents.

kafka.javaToolOptions in packages/apps/kafka/templates/_jvm.tpl truncates the memory limit to an integer. For memory: 1.1Gi it renders -XX:MaxRAM=1181116006, while Kubernetes rounds the same quantity up to 1181116007. One byte under the limit is harmless. Rounding up would still match what the downward API hands the operator JVM.