Trigger.dev v4.7.0 moves concurrency controls to tasks

Trigger.dev v4.7.0 moves concurrency configuration from queues onto tasks, while leaving the queue-level setting available but deprecated. Tasks can combine a perKey ceiling for each concurrencyKey pool with a total cap covering all runs, including runs without a key. Previously, a per-tenant limit did not constrain aggregate task activity, so ten tenant pools capped at one could still run ten jobs concurrently. Named concurrency limits let separate tasks share a bound while retaining separate queues; a task can hold up to two named limits and one inline limit, and starts only when all have capacity. Builders can inspect, change, reset, pause, or resume limits through the new concurrencyLimits namespace. Trigger.dev Cloud enforces the controls now, while self-hosted installations require the v4.7.0 image; older servers accept the option without enforcing it.