Long-running workflows starve under steady arrival of fresh workflows on rate-limited task queues

Problem

Without aging, a long-running workflow's wall-clock to completion is turns × per-turn-wait, where per-turn-wait is set by current queue contention and is independent of how long the workflow has already been running. A workflow that has been running for 30 minutes and just emitted the activities for turn 15 competes for queue slots on equal footing with a brand-new workflow's turn-1 activities — from the matcher's point of view both bursts were created now, so they're indistinguishable.

Under steady arrival of fresh workflows on a rate-limited task queue, an older workflow's per-turn-wait doesn't shrink as it ages, so its total wall-clock grows linearly with turn count even though it has invested significant time already. Aging gives the platform a way to bias dispatch toward long-runners so they pay down their backlog faster than fresh arrivals, instead of treating them identically.

Context

Observed running agent workflows (20–50 LLM turns, tens of minutes to hours each) with tool activities on a rate-limited task queue (MaxTaskQueueActivitiesPerSecond set, the documented pattern). Related closed issue: #2517 — its conclusion (single-partition queues are FIFO, balanced partitions are FIFO-ish) holds for independent producers, but a workflow turn produces a same-partition burst so the variance source is the workflow, not the producer mix.

Draft of one approach at #10243 (in-matcher age tracking + bounded effectivePriority boost). Not married to it — mainly want to align on the problem.