feat(provisioning): provision correlation rules from KEEP_CORRELATION_RULES

[aditya-786]

Why are these changes needed?

The startup provisioner (keep/api/config.py:provision_resources) configures providers, workflows, dashboards, deduplication rules, and mapping rules from Helm values, but correlation (rules-engine) rules were left out. Today the only ways to create one are the UI, the SDK, or POST /rules, so a GitOps deployment cannot declare the alert grouping rule next to the workflow that uses the same CEL filter, and operators have to POST /rules after every cluster bootstrap.

This adds provision_correlation_rules_from_env, giving correlation rules the same env-driven provisioning the other resources already have. Closes #6563.

What changed

• keep/api/bl/correlation_rules_provisioning.py (new): provision_correlation_rules_from_env(tenant_id), mirroring provision_deduplication_rules_from_env. KEEP_CORRELATION_RULES holds a JSON array (or a path to a .json file, dispatched by the same regex the dedup provisioner uses) of rule specs in the POST /rules schema (ruleName, celQuery, sqlQuery, timeframeInSeconds, timeUnit, groupingCriteria, createOn, resolveOn, incidentNameTemplate, incidentPrefix, threshold, requireApprove).
• On every startup the DB is reconciled to the env: upsert by ruleName, delete provisioned rules that are no longer present, and never touch UI-created rules (is_provisioned=False). Unsetting the env var deprovisions everything the provisioner owns. Rolling restarts are idempotent.
• Each celQuery is compiled at provision time; a spec that is missing a required field or has an unparseable CEL is logged and skipped, so one bad rule does not block the others.
• is_provisioned column on Rule + Alembic migration b3f1c9a24d70 (on the current head 67ff7efffed4), tracking which rules the provisioner owns. Mirrors the flag added to MappingRule.
• db.create_rule gains an is_provisioned=False parameter (same shape create_deduplication_rule already has).
• provision_resources() calls the new function right after provision_mapping_rules_from_env.

Example values.yaml:

keep:
  backend:
    env:
      - name: KEEP_CORRELATION_RULES
        value: |
          [
            {
              "ruleName": "critical-alerts-correlation",
              "celQuery": "severity == \"critical\" && !name.startsWith(\"Data\")",
              "sqlQuery": { "sql": "severity = :severity", "params": { "severity": "critical" } },
              "timeframeInSeconds": 600,
              "timeUnit": "seconds",
              "createOn": "any",
              "resolveOn": "never",
              "threshold": 1
            }
          ]

Notes on scope

• The Helm chart lives in the separate keephq/helm-charts repo, so exposing a correlationRules key in the chart templates is a companion change there; this PR is the backend that reads the env var (same split as the existing dedup/mapping provisioning).
• On the matches() footgun the issue raises: the pinned cel-python in this repo does evaluate name.matches('^Foo') (returns a bool), so that specific case does not reproduce here. Provision-time validation therefore compiles the CEL to catch genuine parse errors rather than attempting a trial evaluation, which would false-negative on any rule referencing fields absent from a synthetic payload.

Checks

• I've made sure the tests are passing.
• Testing Strategy
  • Unit tests

tests/test_correlation_rules_provisioning.py (11 tests, mirroring the mapping/dedup provisioning tests): create, multiple, idempotent, update-in-place, deprovision-on-removal, deprovision-on-unset, leave-UI-rules-untouched, skip-invalid-CEL, skip-missing-field, load-from-.json-file, and clean no-op. All pass locally; the rules-engine suite (tests/test_rules_engine.py) stays green.