grm_cel: escalation cron — batching, per-owner access precompute, per-ticket error isolation

[gonzalesedwin1123]

check_escalations scans every open ticket in one uncommitted transaction with no batching (contrary to docs/principles/performance-scalability.md at scale), and one ticket raising a non-AccessError (e.g. a ValidationError from a ticket constraint) aborts the entire hourly run for all subsequent tickets — there is no per-ticket isolation. The per-ticket rule re-search is already hoisted (PR #415 review fixes). Remaining work:

1. Batch the ticket scan (queue_job or windowed processing per the performance principle).
2. Precompute per-owner allowed-ticket sets (tickets.with_user(owner)._filtered_access("write")) once per pass — keeping the original sequence, id iteration order: routing is first-match-wins and escalation is last-writer-wins, so any owner-grouped loop changes which rule wins and the final ticket state (this is why the restructure proposed in PR security(grm): evaluate rules as their owner, scope portal tickets, guard entry points (#379, #380, #381) #415's review thread was not taken as written).
3. Per-ticket error isolation: wrap the per-ticket body so one failing ticket logs and continues instead of killing the pass.

From the PR #415 review thread on grm_escalation_rule.py:511.

[gonzalesedwin1123]

Partial fix landed in #415 (round-2 review): check_escalations now resolves the active rule set and each rule's owner once per pass (warnings logged once, not once per ticket), and one failing ticket is rolled back and logged instead of aborting the pass (except Exception after the per-escalation savepoint). A rule also applies at most once per ticket, which removes most of the repeated work the hourly pass used to do.

Still open here: batching the open-ticket scan and precomputing per-owner access sets.