[Feature]: Pod Sandboxing (Kata): expose virtio-fs rootfs sharing mode (block-device passthrough) as a tunable for I/O-heavy workloads

**Summary**

We're running a Node.js workload on AKS Pod Sandboxing (`kata-mshv-vm-isolation`) that repeatedly spawns fresh `worker_threads`, each dynamically importing a dependency tree of ~1200+ files. We measured this module-graph resolution taking ~6-7s on average inside Kata pods vs ~1-4s for the identical code/image on regular (non-sandboxed) node pools in the same cluster — roughly a 2-3x+ slowdown, worse on some samples.

We instrumented the code to rule out other causes before concluding this is filesystem-sharing overhead:
- CPU request raised from 100m to 2000m (matching the limit): no change.
- Memory request raised to match the limit (ruling out guest memory ballooning): no change.
- Node's built-in V8 compile cache (persisted to an emptyDir, confirmed populated with ~1200 entries across reinits): no change.
- Critically, **reusing the same pod across multiple sequential operations does not amortize the cost** — the 2nd+ module-graph load on an already-running pod costs the same as the first (cold) one. This suggests the guest-side dentry/attribute cache for the virtiofs mount is short-lived or disabled, so every file resolution re-triggers a full host round-trip regardless of whether the same pod already resolved that file moments earlier.

**Ask**

Kata Containers documents block-device passthrough for the container rootfs as giving "much better I/O performance" than virtio-fs for exactly this kind of many-small-file workload (docs: kata-containers.github.io/kata-containers/design/architecture/storage). Is there any way to opt into that (or into virtiofsd DAX/cache tuning) for AKS Pod Sandboxing pods — e.g., via a `RuntimeClass` parameter or pod annotation, similar to how Pod VM memory sizing is already exposed? Right now this seems entirely managed with no user-facing tuning surface.

Happy to share more reproduction detail if useful.