[BUG] Replay of task with bad limit expr bypasses limits, poisons step's limit cache for 5mins #4874

Engine v0.105.16 (tag v0.105.16 +1 commit, 7c89ec556). All line refs are that tree.

Bug 1 — replay never evaluates rate-limit expressions.
  insertTasks (pkg/repository/task.go:2206) gates on stepConfig.ExprCount > 0 (:2500),
  evaluates each "StepExpression" via ParseAndEvalStepRun (:2523), persists results to
  v1_task_expression_eval (:2757 -> :4196). replayTasks (:2788) has no counterpart block:
  it evaluates only v1_step_concurrency expressions (:2923) and never calls
  getStepExpressions (:3213, sole caller :2217). ExprCount appears at exactly :2500 and
  :3221. A task failed at insert has zero eval rows; replay re-queues it without
  re-evaluating and without re-failing it.

Bug 2 — a step-level verdict inferred from task-level evidence, then cached.
  queueRepository.GetTaskRateLimits (pkg/repository/scheduler_queue.go:582-821) builds
  rate limits solely from v1_task_expression_eval (:625). Two identifiers, do not
  conflate: stepsWithRateLimits is a call-local map[uuid.UUID]bool (:596) that never
  escapes the function; cachedStepIdHasRateLimit is a *cache.Cache field on
  queueRepository (:137, constructed :141 with a 5-minute TTL).
  stepsWithRateLimits[stepId] is set true only on seeing a DYNAMIC_RATE_LIMIT_KEY eval
  row (:644); its only other writer (:800) iterates ListRateLimitsForSteps over
  "StepRateLimit", which is always empty under v1 — every rate limit, including fully
  static ones, is stored as "StepExpression" rows (workflow.go:1085), so that path can
  never rescue a false verdict. The local map is then copied into the cache, one entry
  per step in the batch (:815-816), and the cache alone drives the early return (read
  :614, return nil,nil at :620-622). The guard requires every step in the batch to be
  both cached and false for skipRateLimiting to stay true (:611-618). The cached datum is
  a bool "does this step have a rate limit", not a limit value — so the failure mode is
  rate limiting skipped wholesale, not a wrong limit applied.

Coupling to #4746: Queuer.hasRateLimits (pkg/scheduling/v1/queuer.go:65) is assigned in
  exactly one place, :274, from len(GetTaskRateLimits(...)) > 0 — the call at :261, with a
  second call site at :856 — and it gates RequeueRateLimitedItems at :226. It is
  write-once-true and never reset. newQueuer (:98) builds its own queueRepository via
  QueueFactory().NewQueue, hence its own 5-minute cache, so a queuer and its cache are
  born together. A freshly leased or rebalanced queuer whose early batches carry no eval
  rows therefore poisons its own cache, receives nil from GetTaskRateLimits, never learns
  hasRateLimits, and never requeues parked items — #4746's symptom by a route that issue
  does not describe (it attributes the unlearned flag to there being no active items at
  all). Code reading only: only the over-admission above is reproduced. Neither fix
  subsumes the other — dropping the queue-local gate leaves GetTaskRateLimits still
  returning no units, and fixing the cache does not help when there are no active items
  to pass in.

Data model: "StepExpression" (definition, per step; kinds KEY/UNITS/VALUE/WINDOW — the
  enum has no non-rate-limit members) -> v1_task_expression_eval (per task, frozen at
  insert) -> "RateLimit" (bucket, per tenant+key).

Measurement trap: "RateLimit".value is a refilling bucket (lastRefill + window), not a
  consumption counter. It reads full again once the window rolls, so it cannot serve as
  after-the-fact evidence. Use v1_task_expression_eval row counts, or saturate the limit
  and observe task status.

Repro (proof.py): limit 1/HOUR, spent by a baseline phase, so any later COMPLETED cannot
  have been throttled. It cancels queued tasks before replaying — a rate-limited task
  sharing the replayed task's scheduling batch supplies eval rows and masks bug 2.

Scope: demonstrated on a single-task workflow. Queue name is stepConfig.ActionId
  (task.go:2231), so batches hold one step and the early return trips readily. Where
  several steps share a queue, every step in the batch must be cached false. Mechanism
  established; field frequency not measured.

Fix direction: derive hasRateLimit from step configuration (ExprCount > 0, or presence of
  "StepExpression" rows) rather than from whether sampled tasks carried eval rows. For
  bug 1, replayTasks should fail the task when a step with ExprCount > 0 yields no eval
  rows, matching insertTasks.