[Feature Request] Expose remaining budget and a configurable override for the 1000-agent-per-workflow lifetime cap

The Workflow tool caps total agent() calls at 1000 per run as a runaway-loop backstop, documented as "set far above any real workflow." For a corpus-scale workflow (e.g. per-partition fetch/judgment passes fanned out across many ecosystems/families, each itself dispatching further per-item sub-calls), that assumption doesn't always hold — a source corpus can grow over time, and nothing in the script has visibility into how close a run is to the ceiling until it hits it and fails outright mid-run, discarding partial progress on whatever stage was in flight (checkpointing mitigates this on resume, but only if the author built checkpointing in the first place).

Two asks, in order of value:

1. Visibility: expose a lifetime-agent-count analog to the existing token budget object (budget.total/spent()/remaining()) — e.g. agentBudget.remaining() — so a script can proactively chunk its own dispatch before hitting the wall, the same way token-budget-aware scripts already do.
2. Override: a settings-level (or env var) way to raise the cap for verified large-scale legitimate runs, mirroring whatever mechanism lands for the concurrency-cap override requested in #79561/#78105/#63938 — these are the same underlying "one fixed number, no caller-facing knob" pattern, just on two different axes (concurrent vs. lifetime total).

Related: #82984 shows the practical usability ceiling is already well below 1000 (UI degrades ~700+), which makes the case for visibility into proximity even stronger — a script has no way to know it's approaching a wall that isn't even where the number says it is.