`ProcessGroup.Adopt` — bringing an already-running external process into the container. Follows the mechanism these options select: a Windows Job Object always can, a Linux cgroup v2 group can (which is what requesting whole-tree limits selects), and neither the POSIX process group nor the FreeBSD process reaper can at all — a reaper contains this process's own descendants, which a foreign process is not.

`ProcessGroup.AdoptByPid` — the same, from a **bare pid** rather than a `System.Diagnostics.Process`. A separate axis because it is answered by a different question and can differ from `Adoption` on the very same host: what it needs is an identity ANCHOR for the number, not a primitive that relocates a process. The Job Object and cgroup v2 mechanisms hold one inherently (a process object; kernel cgroup membership). The POSIX process group — which cannot `Adopt` at all — can still track a foreign pid against a re-verified start-time token, so it is `Qualified` wherever this host has a reader for one (Linux `/proc`, macOS `proc_pidinfo`) and `Unsupported` where it does not (the BSDs), rather than tracking a bare number teardown would later SIGKILL whoever holds. The FreeBSD process reaper is answered on that same row — it delegates this verb to the process group underneath it and adds no anchor of its own — so in practice it reports that `Unsupported`.

Whether `ProcessGroup.Create(options)` can succeed on this host, and under what qualification. `Unsupported` carries the precondition behind the typed error `Create` returns (a `ProcessError.ResourceLimit` for a cap nothing here can enforce, a `ProcessError.Unsupported` for a concept this platform does not have at all). `Available` means that nothing in these options is refused up front here — it is not a promise that the OS call cannot fail. Creating the native container is exactly the part a snapshot must not run, so a Job the host will not hand out, or a cgroup whose controllers cannot be delegated, still surfaces at `Create`. Where that second failure is *expected* rather than exceptional — the cgroup v2 case, which cannot be settled without attempting the write — this is `Qualified` and says so.

The external helper binaries this platform's spawn paths must load, each with what it is needed for and whether this host holds it. Only the helpers that actually participate on this platform are listed. A fresh list each read, so a caller can never mutate the snapshot through it.

`Command.KillOnParentDeath` — reaping a child when its parent dies *suddenly* (a crash, `SIGKILL`, `TerminateProcess`), which no `Dispose` or finalizer can cover. `KillOnParentDeathScope` reports how far the cleanup reaches where it is available.

The platform-fixed *scope* of that cleanup — the whole tree (Windows), the direct child only (Linux), or nothing (macOS/BSD). Identical to `Command.KillOnParentDeathScope()`, and reported independently of whether the verb was requested.

The OS primitive `ProcessGroup.Create` would contain the tree with for these options on this host — the same choice the real creation makes, decided from the same platform facts. `None` when these options cannot be honoured here at all, in which case `Creation` names what they would need.

`Command.Pty` — starting a child on a pseudo-terminal. Reported from the very host gate the spawn applies (the ConPTY entry point on Windows; the `setsid --ctty` helper plus `/dev/ptmx` on POSIX), so the report cannot drift from what a real PTY spawn would do.

`RunningProcess.ResizeAsync` — resizing a PTY's window. Available wherever a PTY run can be started here; a run started WITHOUT `Command.Pty` is refused with `ProcessError.Unsupported` on every platform, which is a property of the run rather than of this host.

What this host can enforce per resource-limit dimension. These answer for the host rather than for the mechanism these options select — see `ResourceLimitCapabilities`.

What the selected mechanism can deliver from the `Signal` vocabulary.