grm_cel: rule ownership lifecycle — archived owners, ondelete=restrict, create_uid fallback

[gonzalesedwin1123]

Three related lifecycle gaps in the owner-identity mechanism from #379 / PR #415:

1. Archived owners keep their scope. with_user() never checks active, and archiving removes neither groups nor GRM team membership — an offboarded officer's rules keep firing at their frozen scope indefinitely. Consider: surface eval_as_user_id.active == False in the rule list view, warn from the cron, or auto-archive such rules.
2. ondelete="restrict" blocks user deletion. A user who owns rules can no longer be deleted (FK violation) — archive is the only offboarding path. Documented in HISTORY as of the PR security(grm): evaluate rules as their owner, scope portal tickets, guard entry points (#379, #380, #381) #415 review fixes; consider a reassign-on-archive wizard if it bites.
3. The or rule.create_uid fallback masks a skipped migration. Post-migration every row has eval_as_user_id; the fallback exists only for rows that missed the backfill, and silently diverges from what the form shows (blank owner, engine uses creator). Once the migration baseline is guaranteed, drop the fallback so a NULL owner is loudly skipped (the warning log from the review fixes already fires).

From the PR #415 review threads on grm_routing_rule.py:299 and grm_escalation_rule.py:549.

[gonzalesedwin1123]

Partial fix landed in #415 (round-2 review): a rule whose owner is archived is now skipped with a warning (both engines), and a Take Ownership button on the rule form re-binds a rule to the acting user (the client may set eval_as_user_id only to itself; anything else is still stripped). That covers the "archived officer keeps driving automation" and "no reassignment path" halves of this issue.

Still open here: ondelete="restrict" vs. reassign-on-delete, and whether the create_uid fallback in owner resolution should stay once every row is backfilled.