[Enhancement]: Configure CPU and memory ceilings for flow workers

Target Component

• Core Services (Frontend UI/Backend API)
• AI Agents (Researcher/Developer/Executor)

Enhancement Description

Flow workers have a default PID limit, but there are no operator-facing environment settings for their CPU bandwidth and RAM ceilings. Limiting the pentagi service in Compose does not limit the separate worker containers that the Docker client creates.

On a shared development or lab host, an operator should be able to budget each worker without editing Go code or updating containers manually after every creation.

Proposed optional settings:

DOCKER_WORKER_CPUS=2
DOCKER_WORKER_MEMORY=4294967296

Both would default to 0 (disabled), preserving existing installations. A positive memory setting would also disable swap for that worker (MemorySwap = Memory); this behavior should be explicit in the configuration documentation.

Technical Details

• Apply the configured ceilings through shared enforcement in normal flow creation (RunContainer) and the startup sandbox probe, including callers that supply their own HostConfig.
• Keep a stricter caller-provided CPU or memory limit; a caller must not raise an operator ceiling.
• Handle both Docker CPU representations (NanoCPUs and legacy quota/period) without creating conflicting settings.
• Validate negative, non-finite, too-small and overflowing values. Refuse an explicitly enabled budget when the daemon reports that the necessary controllers are unavailable.
• Check an existing worker against enabled ceilings before reuse. Refuse incompatible workers with a recreation message rather than deleting their data or silently retaining unlimited resources.
• Keep the existing 2048 PID default, capability policy, image selection and networking unchanged.
• Add regression tests, Compose/environment wiring and configuration documentation. No new dependency or database migration is needed.

This complements the PID guard introduced in #355. It is a per-worker availability control, not an authorization boundary for someone who already controls the Docker API. Aggregate deployment budgets, disk quotas and network isolation are separate concerns.

Designs and Mockups

No UI change is proposed.

Alternative Solutions

• Compose cpus/mem_limit on the control service: useful for the API process, but does not bound dynamically created workers.
• Manual docker update: must be repeated for newly created workers and is easy to miss.
• Fixed nonzero defaults: change existing workload capacity. Optional limits offer a smaller, backward-compatible first step.

Verification

• I have checked that this enhancement hasn't been already proposed.
• This enhancement aligns with PentAGI's goal of autonomous penetration testing.
• I have considered the security implications of this enhancement.
• I have provided clear use cases and benefits.