Define bounded retention for ACP client processes #5620

Context

PR #5224 retains one official ACP child process per Maka conversation after its first prompt, including while the conversation waits for the next turn. This is the PR 2 continuity rule in #5103: closing the Desktop UI does not retire the task. Task retirement and Plugin/Host teardown release owned process trees, but PR 2 has no idle timeout or process-count cap. A long-running Host can therefore accumulate child processes.

PR 2 records this operational limit rather than evicting a usable task into history_only. PR 3 in #5103 owns restoration of the same external Session after process loss; it does not itself commit to a process-retention policy.

Decision and follow-up

After PR 3 establishes the real Agent's restore behavior, decide how to bound ACP client process retention. Compare an idle timeout, an LRU/process cap, an admission cap, or a combination. Account for process and helper resources, multiple Maka conversations, active prompts and model changes, cancellation, and tasks whose history remains readable after their process is retired. Define the user-visible readiness and continuation behavior before implementing eviction.

Acceptance criteria

• Document the chosen limit, its rationale, and the effect of reaching it.
• No active prompt, configuration change, or process cleanup races with retirement.
• Retiring a process terminates its owned tree and releases in-memory ownership.
• A retired conversation either restores the same external Session or clearly reports that continuation is unavailable; it never silently creates a replacement Session.
• Add controlled-process tests for the selected policy and its boundary cases.

Refs #5103 and #5224. This issue is separate from PR 3's restoration deliverable.