True PID namespace isolation for process-isolated containers (server silos)

Start by tracing the server silo's namespaced object-manager view and the process-enumeration entry points named in the issue, including NtQuerySystemInformation and Get-Process. Then review the containerd/runhcs capability path. Done would require container-local PID enumeration and PID 1 behavior, plus a capability that reports these semantics to CRI.

Is your feature request related to a problem? Please describe.
Server silos don't give a container a fully isolated PID namespace the way Linux pid_ns does. Process enumeration and signaling inside a Windows container can still reflect host-relative process state rather than a clean, container-local view starting at PID 1. Concretely:

1. Tools inside the container that enumerate processes (Task Manager equivalents, Get-Process, monitoring agents) don't reliably see an isolated view scoped to just the container's own processes — behavior differs from what image authors coming from Linux expect, and from what container runtime docs imply "process isolation" guarantees.
2. There's no container-local PID 1 with the usual Linux semantics (reaping orphaned children, being the signal target for container-wide shutdown). Entrypoint scripts and process supervisors ported from Linux images that rely on PID 1 behavior (zombie reaping, signal propagation) behave differently or require Windows-specific workarounds.
3. This is also a security-relevant boundary: full host PID visibility from inside a container widens the information a compromised container process can gather about sibling workloads on the same node, which is inconsistent with what "isolation" implies to anyone coming from Linux/Kubernetes multi-tenant assumptions.

Describe the solution you'd like
Extend the server silo's namespaced object manager view to include a genuine PID namespace:

• Container-internal process enumeration APIs (NtQuerySystemInformation/Get-Process/Task Manager) return only processes inside the silo, with PIDs remapped to a container-local numbering space starting at 1 for the entrypoint process.
• The entrypoint process behaves as PID 1 for signal/shutdown purposes — container stop delivers its termination signal to PID 1 and orphaned descendants are reparented/reaped within the silo, matching the behavior container authors already rely on for Linux images.
• Surface this as a silo capability queryable by containerd/runhcs so CRI can report accurate Started/process-tree info without falling back to host-relative process data.

Describe alternatives you've considered

• Leaving PID visibility as-is and documenting the difference: doesn't fix the entrypoint-script portability problem or the information-disclosure angle, just documents it as a known limitation.
• Hyper-V isolation: gets a real isolated kernel and therefore a real PID namespace "for free," but at full per-container VM cost — not a fix for the shared-kernel case this ticket targets.
• Handling PID-1 semantics entirely in userland (e.g., a tini-style init shim baked into base images): mitigates the signal/reaping half of the problem today, but doesn't address process-enumeration isolation, which requires kernel/silo-level support.

Additional context
Filed as a follow-up to #[syscall/capability filtering ticket — https://github.com/microsoft/Windows-Containers/issues/649], part of the same feature/performance parity-with-Linux-containers effort. This one is scoped purely to PID namespace semantics; user-namespace UID remapping (rootless containers) is a related but architecturally distinct ask we're tracking separately.