Register the runner (see `AddProcessKit`) and bind the `ProcessKitOptions` defaults from a configuration section (e.g. `configuration.GetSection("ProcessKit")`). **Trimming / AOT:** this overload binds options by reflection (`Configure<TOptions>(IConfiguration)`), so it is not trim-/AOT-safe — use the `Action<ProcessKitOptions>` overload from a trimmed/AOT app.

Register the runner (see `AddProcessKit`) and configure the `ProcessKitOptions` defaults (default timeout, working directory) applied to every DI-resolved run.

Register `IProcessRunner` (a singleton `JobRunner`). When the container also has an `ILoggerFactory`, the runner is wrapped so every run it drives emits ProcessKit's structured lifecycle events under the `ProcessKit` category (argv/env never logged); configured `ProcessKitOptions` defaults are applied to each command. A pre-existing `IProcessRunner` registration is left untouched.

Register a keyed `CliClient` for `program` under `name`, with no extra defaults (see the `configure` overload).

Register a **keyed** `CliClient` for one external tool under `name`, so an app injects it by role (`[FromKeyedServices("git")] CliClient git`). The client runs through the container's registered `IProcessRunner` when present (so it is logger-aware and honours a shared group / test runner), otherwise a default `JobRunner`. `configure` applies shared defaults via the `CliClient` builder (`WithDefaults` — timeout, working directory, environment, encoding, ok-codes, …).

A shared container-managed group (see `AddProcessKitGroup`) that also binds the `ProcessKitOptions` defaults from a configuration section. **Trimming / AOT:** this overload binds options by reflection (`Configure<TOptions>(IConfiguration)`), so it is not trim-/AOT-safe — use the `Action<ProcessKitOptions>` overload from a trimmed/AOT app.

A shared container-managed group (see `AddProcessKitGroup`) that also configures the `ProcessKitOptions` defaults (timeout / working directory) applied to every run through it.

Register `IProcessRunner` backed by a **shared, container-managed `ProcessGroup`** — every run goes into one kill-on-dispose container whose lifetime is the provider's, so disposing the provider reaps the whole tree. The `ProcessGroup` is also registered directly (inject it for tree control). Logger-aware and options-applying like `AddProcessKit`. Call this **instead of** `AddProcessKit` when you want a shared group; both use `TryAdd`, so the first wins.