Adopt bounded local-concurrency policy for Zed Rust task/process execution #107

Goal

Establish an organization-level concurrency policy for Zed Rust tooling so repositories cannot accidentally consume unbounded local resources through ad hoc thread/process spawning or unbounded in-memory work queues.

Primary implementation tracker: zed-pkg/zed-cli#472

Proposed policy

For local task/build/install/package execution paths that can fan out work:

• use a fixed-size reusable worker pool or another explicitly bounded executor;
• use a bounded job queue with defined backpressure/saturation semantics;
• do not use naked/ad hoc std::thread::spawn in fan-out paths unless the site is narrowly justified and independently bounded;
• bound subprocess concurrency separately from worker-thread concurrency;
• derive safe defaults conservatively and keep explicit user overrides (--jobs, config, etc.) validated;
• ensure shutdown joins workers and does not leak background work past the command lifetime;
• test concurrency/resource invariants with large synthetic workloads;
• keep task identity/deduplication and locking semantics race-safe;
• prefer a small auditable scheduler abstraction over introducing a heavyweight runtime solely for bounded fan-out.

Suggested reusable invariants

1. live worker threads <= configured worker count;
2. live child processes <= configured process budget;
3. queued jobs <= configured queue capacity;
4. input/task graph size cannot directly determine thread count;
5. queue saturation produces explicit backpressure rather than memory growth;
6. all workers/children are reaped before the owning command returns;
7. concurrency configuration rejects zero/invalid values and has a documented default;
8. nested work cannot deadlock the scheduler by synchronously filling its own queue.

Enforcement ideas

• add organization guidance under the shared .github repository / contributor instructions;
• add a lightweight static check for suspicious task-path thread::spawn / unbounded channel usage where practical;
• require explicit tests for max thread/process/queue occupancy when a repo introduces parallel execution;
• have zed-pkg lifecycle hooks / git hooks invoke the check in repositories that own local execution machinery;
• document approved primitives/patterns and exception criteria.

Initial scope

Start with zed-pkg/zed-cli and the native zed task runtime, then apply the rule opportunistically to other Rust repositories that execute bounded local work.

Acceptance criteria

• shared policy documented in zed-pkg/.github;
• implementation tracker remains cross-linked to zed-cli#472;
• enforcement mechanism defined for task/process execution repositories;
• zed-cli adopts a fixed worker pool + bounded queue;
• tests prove thread/process/queue bounds;
• exception process for legitimately dedicated threads is documented;
• policy is suitable for reuse by zed-pkg lifecycle hooks and git hooks.