fix[backend](incidents): added mark as incident alerts on incident cr…

[AlexSanchez-bit]

No description provided.

[github-actions]

🛑 AI review — High/critical findings

One or more high/critical issues were found. Please review and fix before merging if they're real.

⚠️ architecture (silas-1.7-pro) — minor findings

Summary: Internal incident/alerts coupling and inconsistent failure handling; no critical path, agent, or contract changes.

• medium backend/modules/incidents/usecase/incident.go:93 — Incident creation now performs an alerts side effect after persistence and only logs failure, which can leave incident and alert state inconsistent. Consider making the alert marking part of the same transaction/use-case or adding compensation/error propagation.
• low backend/modules/incidents/connectors/gateways.go:11 — AlertsGateway.MarkAlertAsIncident includes createdAt that the adapter ignores. Remove the unused parameter or use it to keep the internal contract minimal.
• low backend/modules/incidents/adapters.go:34 — Incidents adapter directly invokes alerts usecase ConvertToIncident, increasing incidents-to-alerts coupling. Ensure this does not create a circular dependency and that incidents remains the orchestration layer.

🛑 bugs (silas-1.7-pro) — high/critical — please review

Summary: Adds MarkAlertAsIncident but the Create call uses undeclared err/alertIDs and swallows failure; adapter ignores createdAt.

• high backend/modules/incidents/usecase/incident.go:98 — The added call references alertIDs, but the visible code uses req.AlertList and does not declare alertIDs; if not defined earlier this is a compile error. Use req.AlertList or declare alertIDs.
• high backend/modules/incidents/usecase/incident.go:98 — The added line assigns to err without declaring it in the visible scope; previous errors use if err := ... so this may not compile. Use if err := ... or declare var err error.
• medium backend/modules/incidents/usecase/incident.go:98 — Failure to mark alerts as incident is only logged and not returned, so Create can succeed while alerts remain unconverted, causing inconsistent state.
• low backend/modules/incidents/adapters.go:32 — createdAt parameter is accepted but never used; if the converted incident should preserve the created time, it is silently dropped.

✅ security (silas-1.7-pro) — clean

Summary: No new vulnerabilities or customer-facing information disclosure identified in the incident/alerts adapter changes.

No findings.

🔴 go-deps — pending updates

🔍 Discovered 30 Go projects

📦 Dependencies with updates available:

  📁 ./plugins/gcp:
     - google.golang.org/api: v0.299.0 → v0.300.0

  📁 ./plugins/aws:
     - github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs: v1.88.1 → v1.89.0

  📁 ./plugins/azure:
     - github.com/Azure/azure-sdk-for-go/sdk/azcore: v1.23.1 → v1.23.2
     - github.com/Azure/azure-sdk-for-go/sdk/storage/azblob: v1.8.1 → v1.8.2

  📁 ./backend:
     - github.com/Azure/azure-sdk-for-go/sdk/storage/azblob: v1.8.1 → v1.8.2
     - github.com/threatwinds/go-sdk: v1.1.27-0.20260819160318-c56c250bc585 → v1.1.36
     - google.golang.org/api: v0.299.0 → v0.300.0

  📁 ./tools/rulecheck:
     - github.com/threatwinds/go-sdk: v1.1.31 → v1.1.36

  📁 ./agent-manager:
     - github.com/threatwinds/go-sdk: v1.1.31 → v1.1.36

  📁 ./log-input:
     - github.com/threatwinds/go-sdk: v1.1.31 → v1.1.36

  📁 ./agent:
     - github.com/threatwinds/go-sdk: v1.1.28 → v1.1.36

  📁 ./collectors/utmstack:
     - github.com/threatwinds/go-sdk: v1.1.31 → v1.1.36

  📁 ./collectors/forwarder:
     - github.com/netsampler/goflow2: v1.3.7 → v1.3.8
     - github.com/threatwinds/go-sdk: v1.1.31 → v1.1.36

  📁 ./collectors/as400:
     - github.com/threatwinds/go-sdk: v1.1.31 → v1.1.36

❌ Please update dependencies before merging.