[Tracking] Feature/performance parity for process-isolated (shared-kernel) containers vs. Linux containers #653

Is your feature request related to a problem? Please describe.

Process-isolated Windows Server containers lag Linux containers on several related fronts — privilege isolation granularity, PID namespace semantics, image layer/filesystem performance, and host/image version coupling. Each gap has its own owner surface and is filed as its own ticket, but they share a common motivation (closing the parity gap without falling back to Hyper-V isolation, which erases the density/startup-time benefit process isolation exists for), so this issue exists to track them as one effort.

Describe the solution you'd like

Track progress against the four scoped tickets below:

• Syscall/capability-scoped restriction policy for process-isolated containers (seccomp/capabilities parity) #649 — Syscall/capability-scoped restriction policy for process-isolated containers (seccomp/capabilities parity)
• True PID namespace isolation for process-isolated containers (server silos) #650 — True PID namespace isolation for process-isolated containers (server silos)
• CimFS-backed overlay mount performance parity with Linux overlayfs for container image layers #651 — CimFS-backed overlay mount performance parity with Linux overlayfs for container image layers
• Decouple container base image version from host OS version for process-isolated containers #652 — Decouple container base image version from host OS version for process-isolated containers

Describe alternatives you've considered

N/A — this issue is a tracking umbrella, not an independent ask; alternatives are discussed per-ticket above.

Additional context

#652 is flagged as the hardest of the four, likely requiring changes below the container runtime layer; the other three are scoped to be independently actionable. Happy to close this umbrella once all four are triaged/assigned if the team prefers tracking via a label or milestone instead.