Add storage/disk support for QEMU ExporterSet virtual targets

[mangelajo]

Summary

QEMU ExporterSet pods need proper guest disk / storage support so lessees can flash and boot images. Without this, the sidecar pattern is limited for real workflows.

Deferred from PR #910 (scope already large).

Background

From PR #910:

…I will handle the storage detail in a follow up PR, this has grown too big. :) and this won't go too far anyway without the storage support.

Related discussion on staging binaries via Kubernetes image volumes once the cluster baseline is 1.36+ (comment) — that is a related optimization for the copy-jumpstarter-exec init container, but the primary gap is guest disk storage for flash/boot.

What needs to be done

1. Define how guest disks are provisioned for ExporterSet QEMU pods (emptyDir, PVC, image volume, OCI artifact, etc.)
2. Wire storage into the QEMU provisioner RenderPod + ExporterConfig enrichment so the QEMU driver can flash/boot

Acceptance criteria

• ExporterSet QEMU pods expose flashable storage usable via existing QEMU driver APIs
• Sample manifests / docs updated
• Basic e2e or documented manual test: lease → flash → boot

Tracking

• Jira: https://redhat.atlassian.net/browse/PITCREW-501
• PR: feat: QEMU ExporterSet sidecar pattern with jumpstarter-exec (PITCREW-487) #910
• Follow-up comment: feat: QEMU ExporterSet sidecar pattern with jumpstarter-exec (PITCREW-487) #910 (comment)

[bennyz]

So i was thinking something like

parameters:
  storage:
    size: "40Gi"
    storageClassName: "gp3"
    accessModes: ["ReadWriteOnce"]

that then on the Pod would be rendered as

  volumes:
    - name: scratch-volume
      ephemeral:
        volumeClaimTemplate:
          metadata:
            labels:
              type: my-frontend-volume
          spec:
            accessModes: [ "ReadWriteOnce" ]
            storageClassName: "gp3"
            resources:
              requests:
                storage: 40Gi

as the ephemeral volume