security(spp_grm_cel): rule-engine entry points are unguarded RPC-callable methods [Severity: Medium]

[gonzalesedwin1123]

Found during the staff review of PR #266, out of that PR's scope.

Finding

Three public @api.model methods drive the GRM rule engine with no access check, so they are dispatchable via call_kw:

• apply_routing — spp_grm_cel/models/grm_routing_rule.py:221-222
• apply_escalations — spp_grm_cel/models/grm_escalation_rule.py:456-457
• check_escalations — spp_grm_cel/models/grm_escalation_rule.py:433-434

Combined with the portal ticket over-grant (see the companion issue on spp.grm.ticket record rules), a portal user can call apply_routing(<any ticket>) to force admin-authored routing rules onto arbitrary tickets — the ticket.write succeeds, and the routing counter is already sudo()'d so nothing blocks it.

check_escalations via RPC currently aborts at the non-sudo counter write and rolls back, but that is incidental, and PR #266 sudo's that write — so the incidental protection goes away. It should be guarded explicitly rather than by accident.

Suggested fix

Either add an explicit check_access / group guard at each entry point, or rename them to _-prefixed internals (Odoo rejects RPC dispatch to underscore-prefixed methods) with thin, guarded public wrappers for the cron and the legitimate sudo callers.

Minor adjacent nit from the same review: _check_condition_cel catches only SyntaxError (grm_routing_rule.py:118, grm_escalation_rule.py:152), so any other parser exception propagates raw instead of becoming a ValidationError. Pre-existing, cosmetic.

Related: #266, #379.