feat: virtiofs rootfs hotplug for LinuxPod on cloud-hypervisor

[crosbymichael]

Allow a container hotplugged into an already-running LinuxPod VM (addContainer after create()) to have a virtiofs (directory-share) rootfs, not just an ext4 virtio-blk image, on the cloud-hypervisor backend.

Host side:

• Generalize CHHotplugProvider.hotplug to branch on the rootfs runtimeOptions (.virtioblk / .virtiofs / unsupported), reusing the per-tag virtiofsd/vm.add-fs machinery factored into a new ensureVirtiofsDevice helper. Make registerMounts the sole writer of the per-VM mount registry so the rootfs is always first and mounts are not double-registered (also fixes a latent ordering bug on the block path). Exclude the rootfs from the /run/virtiofs holding-dir loop in addContainer.

Guest side (fixes a pre-existing, feature-independent bug):

• The addContainer-after-create (runtime hotplug) path had never been exercised by any test. cloud-hypervisor adds hot-plugged virtio-blk/virtio-fs devices to the guest PCI bus but the guest does not auto-probe them, so a mount by /dev/vdX or virtio-fs tag fails (ENOENT / tag-not-found) for ALL CH hotplug.
• vminitd's mount RPC now, on a mount failure for a hot-plug-candidate source (virtiofs type or /dev/vd* source), forces /sys/bus/pci/rescan and retries with a bounded wait. Scoped so boot-time and non-device mounts are unaffected.

Tests / build:

• First coverage of LinuxPod.addContainer after create() (CH-only; VZ has no runtime hotplug): pod hotplug virtiofs rootfs and pod hotplug block rootfs, registered in a Linux-only test list, plus a directory-rootfs unpack helper.
• make linux-integration gains an optional FILTER passthrough (make linux-integration FILTER="pod hotplug").