Execution: load-testing harness and published capacity numbers for AMS's iterate-loop under concurrent load

[JSONbored]

Problem

ORB's #4913 tracks load-testing tooling and published throughput numbers to support its own hosted capacity planning. AMS has no equivalent — there is currently no data on how AMS's iterate-loop behaves under concurrent, multi-tenant-like load on shared infra, which leaves the per-tenant scheduling design work in this milestone without real numbers to design against.

Area

AMS / Scaling & capacity

Proposal

Build a load-testing harness that runs multiple concurrent iterate-loop instances against shared infra, reusing the existing driver-injection pattern (cli-subprocess-driver.ts) to simulate agent work without spending real API budget, and publish baseline capacity/throughput numbers from the runs.

Deliverables

• A load-testing script/harness checked into the repo, using the existing fake-driver injection pattern to run concurrent iterate-loop instances without real API spend
• A published results document with baseline concurrency/throughput numbers from running the harness against shared infra

Resources

• packages/gittensory-engine/src/miner/iterate-loop.ts, cli-subprocess-driver.ts (for fake-driver injection)
• ORB's Build load-testing tooling #4913 (parallel precedent for the same load-testing/capacity-numbers work)

Boundaries

• Execution and measurement only against existing, already-injectable code paths — this issue does not change the concurrency model itself.
• Findings from this issue feed directly into the per-tenant scheduling and queue-fairness design issue in this milestone; the published numbers should be referenced there rather than re-measured.
• Must use the existing driver-injection pattern to avoid real API spend during load testing — do not run the harness against live agent-driver calls.

[linear-code]

JSO-3750