vlagent: replace the default tmpDataPath hostPath volume with emptyDir

Describe the bug

In vlagent, when k8sCollector.enabled: true is set, the operator backs -tmpDataPath with a hostPath volume at the fixed node path /var/lib/vlagent-data by default. This can cause the following issues:

1. Kubelet’s fsGroup ownership management does not apply to hostPath volumes. The directory is created on the node with 0755 root:root permissions and ownership, which can cause permission issues when runAsNonRoot: true is configured or on platforms such as OpenShift, where SCC admission can assign the container UID and fsGroup from the namespace’s permitted ranges, leaving the process unable to write to the root-owned host directory.
2. Since the path is fixed rather than unique to each CR, two VLAgent CRs with k8sCollector enabled and scheduled on the same node may write to the same directory.
3. Deleting the VLAgent still leaves its data on the node.

For comparison, VMAgent does not have these issues. By default, its persistent queue uses an emptyDir volume mounted at /tmp/vmagent-remotewrite-data.

To reproduce

Create a VLAgent with a non-root security context:

apiVersion: operator.victoriametrics.com/v1
kind: VLAgent
metadata:
  name: example
spec:
  useStrictSecurity: true
  securityContext:
    runAsUser: 65534
    runAsNonRoot: true
    fsGroup: 65534
    supplementalGroups: [0]
  k8sCollector:
    enabled: true
  # ...

Describe the solution you’d like

Back tmpDataPath with an emptyDir volume and mount it at a non-host path, the same approach as VMAgent.

Start by locating the VLAgent reconciliation or rendering path that handles k8sCollector and tmpDataPath, then compare it with VMAgent’s default persistent queue configuration. Done means the default VLAgent volume is an emptyDir mounted at a non-host path, while the supplied non-root security-context example can write successfully; run the relevant operator tests.