Support commit_status and pull_request_comment actions for non-GitHub providers

[krrish175-byte]

Please describe the enhancement

Currently, the commit_status and pull_request_comment alert and remediation engines are hardcoded to rely on the GitHub provider interface (provinfv1.GitHub). If a rule is evaluated against a non-GitHub provider (such as GitLab or BitBucket), the engine logs a debug message ("provider is not a GitHub provider. Silently skipping alerts.") and falls back to a NoopAlert / NoopRemediate.

While this safely prevents engine panics, it leaves users without pull request feedback support on other Git platforms and silently swallows intended operations.

Solution Proposal

We should decouple these actions from github.RepoStatus and github.PullRequestReviewRequest structs so they can operate under a generic provider interface. The evaluation engines should dynamically call the appropriate provider's PR comment or status check APIs based on the active provider context, allowing commit_status and pull_request_comment to work universally across all supported version control providers.

Describe alternatives you've considered

• Explicit Validation: Continue skipping gracefully with NoopAlert/NoopRemediate, but throw a validation error during profile creation if a user explicitly configures these actions on a profile bound to a non-GitHub provider.
• Specific Action Types: Create provider-specific action types (e.g. github.qkg1.topmit_status, gitlab_commit_status), although this harms the reusability of rules.

Additional context

Spun off from PR review feedback in #5977. Related code locations (e.g., internal/engine/actions/alert/alert.go):

client, err := provinfv1.As[provinfv1.GitHub](provider)
if err != nil {
	zerolog.Ctx(ctx).Debug().Str("rule-type", ruletype.GetName()).
		Msg("provider is not a GitHub provider. Silently skipping alerts.")
	return noop.NewNoopAlert(ActionType)
}

Acceptance Criteria

• commit_status and pull_request_comment actions function correctly when applied to a GitLab (or other supported non-GitHub) provider without failing or silently skipping.
• Generic interfaces are used to pass PR feedback payloads to the underlying VCS provider instead of directly casting to provinfv1.GitHub.

[nishantbkl3345-ship-it]

Hi, I took some time to go through this issue and the related discussion in #6261.

From what I understand, the main goal here is to decouple PR feedback actions from the GitHub-specific provider by introducing a more generic interface, so that features like pull_request_comment (and possibly commit_status) can work across other providers without falling back to Noop.

The idea of moving towards provider-agnostic interfaces (like a ReviewPublisher-style abstraction) and reusing common operations (create/update/dismiss review) seems like the right direction, especially to keep the behavior consistent across providers.

I’d like to work on this. I’m planning to start by:

• identifying all GitHub-specific usages in the current alert/remediation flow
• designing a minimal generic interface for PR feedback
• implementing it first for pull_request_comment before expanding scope

Please let me know if this approach aligns with what you had in mind 👍