Re-tune queue concurrency for multi-customer volume

[JSONbored]

Problem: Queue batch size and concurrency are hardcoded and explicitly sized (per an in-code comment) around today's small, known set of repos and their shared GitHub rate-limit bucket — not a multi-customer volume model.

Area: ORB / Cloud

Proposal: Make these settings configurable and re-derive sane defaults for a plausible multi-tenant volume, informed by the scaling work elsewhere in this milestone.

Deliverables:

• Configurable, better-justified queue tuning, documented with the reasoning behind the new defaults.

[linear-code]

JSO-3552

[JSONbored]

Re-scoping — the per-tenant fairness half of this already shipped: src/selfhost/installation-concurrency-admission.ts (citing #2970) already stops one installation's background jobs from starving every other installation's. QUEUE_CONCURRENCY/QUEUE_BACKGROUND_CONCURRENCY are already configurable env vars too. What's still genuinely missing: re-derived, documented default values sized for real multi-customer volume (today's defaults were tuned for single-operator load). Narrowing this issue to that gap specifically.

[JSONbored]

Narrowing this after checking what's actually possible — the "make these settings configurable" half of the proposal runs into a real platform constraint, not a choice.

max_batch_size/max_concurrency/max_retries/retry_delay (wrangler.jsonc's queues.consumers block) are Cloudflare Queues consumer-binding attributes — read by Cloudflare's control plane at wrangler deploy time, before any Worker code runs. Unlike a docker-compose port mapping or a wrangler.jsonc vars entry, the Worker has no way to read or override these via env.SOMETHING at runtime; there's no mechanism (no build-time templating, no envsubst step) between this repo's committed wrangler.jsonc and wrangler deploy either. They can only be re-tuned by editing the literal values directly, or — once a second deploy target actually exists — via that target's own named-environment queues.consumers override block. There's only one deploy target today.

The "re-derive sane defaults... informed by the scaling work elsewhere in this milestone" half has a separate, real blocker: I don't have access to production job-volume data (job rate, distinct-installation count, actual GitHub rate-limit headroom observed) from a worktree — inventing new numbers without that would be a guess dressed up as a calculation, and the sibling scaling-audit docs (packages/loopover-miner/docs/global-singleton-tenant-audit.md et al.) don't carry queue-throughput numbers either.

What I did do: rewrote the wrangler.jsonc comment (was anchored to one specific repo, metagraphed, from the original #1283 incident) to document the actual governing constraint in durable, formula form — max_batch_size × max_concurrency bounds concurrent in-flight GitHub calls against one installation's rate-limit headroom — so re-tuning later starts from a stated principle instead of one repo's historical sizing.

Re-tuning the actual numbers needs a live dashboard/audit_events query for real volume, not something this session can produce. Leaving open for whoever has that access.

[JSONbored]

The scaling/capacity work this was waiting on (#4903-#4913) is now entirely closed. Unblocked and ready for a contributor to retune queue batch size/concurrency with real justification against that already-shipped work, rather than the original hardcoded small-fleet assumption.