[Request]: expose per-container PID limits in LinuxContainer.Configuration

[sturdy4days]

Summary

Expose an optional per-container PID/task limit through the public LinuxContainer.Configuration API and map it into OCI linux.resources.pids.limit.

Motivation

The lower layers already model the control: LinuxResources.pids exists in the OCI model, and vminitd's cgroup v2 manager writes pids.max. The current high-level configuration maps CPU and memory but provides no public way to request a PID limit. This prevents callers from applying a per-workload task ceiling even though the guest cgroup plumbing is present.

Proposed shape

• Add an optional pidsLimit to LinuxContainer.Configuration.
• Preserve omission as today's behavior.
• Map an explicitly configured value to OCI linux.resources.pids.limit before the workload starts.
• Preserve OCI semantics at this library boundary: -1 means unlimited and 0 remains a valid OCI value. Higher-level CLIs can impose stricter UX policy if needed.

Acceptance criteria

• Integration coverage verifies the exact guest pids.max value for a finite limit.
• Coverage verifies that the default/omitted configuration remains unchanged.
• A bounded workload reaches the task limit and receives the expected fork/clone failure while management remains responsive.
• Requested enforcement fails before workload execution if the necessary controller cannot be applied; it must not silently run unbounded.

Related infrastructure: #322 and #620.