admission: observe transient elastic CPU waiters via sticky bit

[dt]

The elastic CPU controller's scheduler-latency listener point-samples the
WorkQueue's hasWaitingRequests at ~1Hz. The granter's tryGrant loop
drains the queue to empty as soon as tokens refill, so the queue spends
most of its time empty even under sustained throttling. The listener's
poll frequently lands in those empty windows and takes the inactive-decay
branch, pulling the utilization limit down toward inactive_point (~12%)
even when scheduler latency is well under target and there is clearly
demand for more elastic CPU.

This PR adds a sticky "had recent waiters" atomic bool on WorkQueue,
set on every Admit enqueue and cleared by an atomic Swap from the
listener each tick. A new elasticCPULimiter.hasOrHadRecentWaitingRequests
ORs this with the instantaneous hasWaitingRequests signal so any
enqueue between two ticks is durably visible to the controller, even if
the queue subsequently drained.

Fixes #170400

Epic: none

Release note (bug fix): Fix the elastic CPU admission controller holding
the elastic-work CPU utilization limit at its inactive floor (~12%) even
when there was sustained demand under the scheduling-latency target. The
controller's 1Hz poll could miss queued work that the granter drained
between ticks, causing it to incorrectly conclude there was no demand
and decay the limit.

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[cockroach-teamcity]

This change is