feat: enforce incident trigger CEL in insert_incident

[ausias-armesto]

Fixes: #6656

Problem

WorkflowManager.insert_incident() only checked whether the incoming event
name (created / updated) was declared on the trigger. It never compiled
or evaluated the trigger's cel expression, unlike insert_events(), which
does this for alert triggers. As a result, a cel guard on an incident
trigger — e.g. !has(incident_id), meant to stop a workflow from re-running
once it has already completed and enriched the incident — had no effect at
all. The workflow ran on every matching event regardless.

Change

insert_incident() now:

1. Finds the specific incident trigger (if any) whose events list contains
   the incoming event name, instead of only checking membership across a
   flattened list of all incident triggers' events.
2. Merges the incident's persisted enrichments onto the IncidentDto (as
   before), so fields set by a prior successful run (e.g. incident_id) are
   visible.
3. If the matching trigger declares a cel, compiles and evaluates it via
   the same celpy environment insert_events() uses, and skips scheduling
   the workflow when it evaluates to false. Evaluation errors are caught,
   logged, and treated as "don't run" rather than raised.

incident.dict() leaves UUID fields (like incident.id) as native Python
objects, which celpy.json_to_cel rejects. The activation payload is built
from json.loads(incident.json()) instead, so pydantic's own JSON encoders
handle that conversion first.