Concurrency cap for parallel Queueable chains

[Mateusz7410]

Motivation

We support priority within a chain, but nothing bounds how many independent
chains run in parallel. A high-volume org enqueuing from many transactions can
saturate Queueable throughput or overwhelm a downstream system. A soft cap on
concurrent framework-managed chains would let teams throttle safely.

Proposal

• A configurable maximum number of concurrent chains via a new
  MaxConcurrentChains__c field on QueueableJobSetting__mdt (or a hierarchical
  custom setting, so service / integration users can be tuned separately from
  everyone else).
• When the cap is reached, new work waits and is picked up as running chains
  complete, instead of enqueuing immediately.

Notes

• Pairs naturally with the chunked-processing job for large-volume work.
• Must stay inside Salesforce async governor limits (chained-Queueable depth,
  flex-queue behavior).

Acceptance criteria

• Setting drives runtime behavior; blank / 0 / negative defaults to 1.
• Apex tests: cap respected, slot freed on chain completion.
• Docs.