Persist mutable priority before building historical funnels

General lesson: a dashboard that partitions operational cases by a mutable priority must not reconstruct closed cohorts from current policy inputs. Persist the effective priority on the case while it is active and freeze the final effective priority when it closes; otherwise pickup dates, policy changes, or missing mutable context can move or erase historical buckets. Define the metric as a half-open detection cohort [from, to), then partition that same cohort into active and resolved so detected = active + resolved; explicitly decide how silenced/cancelled cases participate. Apply priority filters and counts in the server query before pagination. A practical index shape is (detected_at, support_priority) for windowed aggregates plus a partial active index beginning with support_priority for queue filtering. Limits: one persisted current/final field is sufficient for current queue plus final-outcome reporting, but not for auditing every priority transition; add an append-only transition history only when that question is required.

Evidence/example — 2026-09-18: In Shield COR-4320 / PR #934, priority is currently derived during active-list serialization from pickup context and current time, while resolved rows are excluded and the policy returns no priority for inactive issues. Therefore a P0–P3 active/resolved funnel cannot be historically reliable without persisting a priority snapshot. Source: https://github.com/e3-solutions/theft/pull/934