[Bug]: rootfs propagation is applied to the host mount tree when the spec omits the mount namespace

When the container spec omits the mount namespace, youki still applies rootfs propagation to "/" during rootfs preparation, and in that case "/" is the host's root. In crates/libcontainer/src/rootfs/rootfs.rs, prepare_rootfs calls mount_to_rootfs unconditionally, and mount_to_rootfs runs mount(None, "/", None, MS_REC|MS_SLAVE) for the default case (no rootfsPropagation in the spec) and then make_parent_mount_private(rootfs). With no mount namespace both calls land on the host mount tree, so container creation recursively strips the peer groups of every mount on the host and marks the rootfs parent private. This mutates unrelated host state silently.

It bit the contest suite in #3725: the ns_itype test creates a container with an empty namespace list, and when it ran in the same parallel batch as the mount_propagation tests, the propagation setup those tests had just done was wiped before their containers were created. runc has the same behavior (prepareRoot in libcontainer/rootfs_linux.go).

Steps to Reproduce

1. Make a shared mount on the host: mkdir /tmp/m && mount --bind /tmp/m /tmp/m && mount --make-shared /tmp/m.
2. Run youki create with a spec whose linux.namespaces has no mount namespace entry (the contest ns_itype test does exactly this).
3. Read /proc/self/mountinfo for /tmp/m: the shared: field is gone and the mount has no optional fields left.

Expectation

Without a mount namespace there is nothing to isolate, so container creation should not touch the host's mount propagation state. youki already special-cases this situation for pivot_root (#240); the rootfs propagation application should be skipped the same way, or at least not applied recursively to "/".

System and Setup Info

Reproduced on kernel 6.17.0-1022-azure (GitHub runner) and kernel 7.0.12-linuxkit (Docker Desktop). runc 1.4.1 shows the same behavior.

Additional Context

• The ns_itype contest test exists because specs may legitimately omit namespaces, so this path is not exotic.
• runc reference: prepareRoot in libcontainer/rootfs_linux.go (MS_SLAVE|MS_REC on "/" plus rootfsParentMountPrivate, called unconditionally from prepareRootfs).
• Discussion with the maintainer: #3725.