v12 - refactor(plugins/rule-flood-guard): reuse existing endpoints instead of a dedicated internal one

[yllada]

What

Removes the dedicated internal-key-gated endpoint (/internal/correlation-rule/deactivate) that plugins/rule-flood-guard was calling, and switches the plugin to reuse the two endpoints that already existed and already power the manual UI flow:

• GET /correlation-rule/search-by-filters?ruleName=<name> — resolve a rule by name
• PUT /correlation-rule/activate-deactivate?relPath=<relPath>&active=false — disable it

Also fixes two bugs found during review of this change, and adds a small usability improvement.

Why

The dedicated internal endpoint was unnecessary: X-Internal-Key already bypasses permission checks on the existing endpoints (authz.HasPermission has if a.Internal { return true }), so the plugin could reach them directly all along. Reusing the existing endpoint also means the guard's automated disables now go through the same code path as a manual disable — including its audit log entry, which the dedicated endpoint never had.

Changes

Commit	What
refactor(backend/eventprocessing)	Delete the unused internal endpoint + handler + DTO
fix(backend/eventprocessing)	activate-deactivate now returns {"changed": bool} (was 204 with no body) — an authoritative, server-derived signal instead of the caller guessing from a stale read. This matters with 2 event-processor instances (worker + manager) both running the guard: only the instance whose call actually flipped the rule sees changed:true, closing a duplicate-notification race
fix(plugins/rule-flood-guard)	Plugin updated to consume the 2 existing endpoints; restores "disable every rule with a colliding exact name" (was accidentally narrowed to "skip if ambiguous" during the first pass of this change); fixes a bug where a partial failure in a name-collision batch could silently drop the notification for the rule that did get disabled; plugin now creates system_plugins_rule-flood-guard.yaml with default values on first run if it doesn't exist yet (never overwrites an existing one)

[github-actions]

🛑 AI review — Sensitive area, extra care recommended

This PR touches critical paths or introduces changes the model cannot judge with sufficient confidence. Review carefully before merging.

⚠️ architecture (gemini-3-flash-lite) — minor findings

Summary: Refactor of internal rule deactivation logic to use public API; minor structural improvement.

• medium backend/modules/eventprocessing/handler/correlation_rule.go:133 — The ActivateDeactivate endpoint now returns a JSON object instead of 204 No Content. While this is a cleaner API, ensure that frontend consumers of this endpoint are updated to handle the new response body structure.
• low plugins/rule-flood-guard/config.go:71 — The writeDefaultConfigIfMissing function performs file I/O with side effects during config loading. Consider moving this to an explicit initialization or migration step to keep the config loader pure.

✅ bugs (gemini-3-flash-lite) — clean

Summary: Refactored rule deactivation logic to use standard API endpoints; minor cleanup of internal routes and improved default config generation.

No findings.

🛑 security (gemini-3-flash-lite) — high/critical — please review

Summary: Refactoring of rule deactivation logic across internal/external boundaries and plugin communication.

• medium backend/modules/eventprocessing/handler/correlation_rule.go:126 — The API endpoint /correlation-rule/activate-deactivate now exposes internal state change information (changed: bool) to the client. Ensure this does not leak sensitive logic or state transitions to unauthorized users.
• medium plugins/rule-flood-guard/backend.go:40 — The plugin now performs rule resolution via a GET request to /api/v1/eventprocessing/correlation-rule/search-by-filters using an internal key. Ensure this endpoint is properly protected by middleware to prevent unauthorized rule discovery.

🟢 go-deps — up to date

No pending Go dependency updates.