feat(run-engine): enforce queue-gates in the vtime dequeue and TTL sweep

The 2a merge integrated main's queue-gates + total-concurrency into the
enqueue/ack/nack/dead-letter vtime commands but left the vtime dequeue and
TTL-expiry sweep interim: flag-off enforced gates, vtime did not. This finishes
the integration so both flag states enforce identically.

Dequeue: the per-candidate serve in tryServe now runs the same admission checks
the flag-off dequeue does. A run is served only when its per-gate limit
(__gatesHaveCapacity) and the total-concurrency headroom both allow it; on serve
it joins the group set, decrements the shared headroom (computed once, spent
across both passes), and acquires its gates. A gate- or total-blocked candidate
is backed off in ckIndex and reported notReady, the same treatment the per-key
concurrency ceiling already gets, so it does not pin the bounded window. The ck
dequeue was a one-caller template after the merge (flag-off is a separate inline
command), so it is now a standalone inline command rather than a slotted
template that shared nothing.

TTL sweep: an expired run now decrements its gate's queued counter, releases its
gate slots, and mirrors the currentConcurrency SREM into the group set, matching
expireTtlRunsTracked. Without this a gated run that TTL-expired leaked its queued
counter and, if it had been dequeued, a group-concurrency slot.

The both-flags construction warning is removed: the combination is now safe.
Flag-off remains byte-identical to main (31/31 scripts). Three tests cover the
combination, each mutation-checked: total-concurrency cap and per-gate cap on
the vtime dequeue, and queued-counter release on vtime TTL expiry. The total
test uses four variants so the cap, not the one-serve-per-variant behaviour, is
what holds it.

Author: 1stvamp