GitLab integration: receive webhooks for automatic state sync

[emyller]

Context: #7000

When a linked GitLab issue or MR changes state (closed, merged, reopened), Flagsmith should update the feature flag's tags automatically.

Scope

• Expose a webhook endpoint for GitLab to call.
• Register webhooks programmatically via the GitLab API:
  • Group webhooks — Premium/Ultimate only; requires Owner role. One hook covers all projects in the group.
  • Project webhooks — Free tier; requires Maintainer or Owner role.
• Subscribe to issues_events and merge_requests_events.
• Webhook secrets should be generated by Flagsmith and stored on the configuration model, not provided by the user. The secret is created when Flagsmith registers the webhook via the GitLab API, and used to validate incoming webhook payloads.

Note

PR #7122 contains a webhook receiver and event-driven tagging (services.py: handle_gitlab_webhook_event, tag_feature_per_gitlab_event) that can be used as a starting point. A few things to consider:

• Webhook auto-registration (calling POST /api/v4/projects/:id/hooks or POST /api/v4/groups/:id/hooks) is not in the PR — that is new work.
• The tagging service looks up the configuration by project_name, which ties it to a single GitLab project. This conflicts with the org-level model defined in GitLab integration: store connection credentials #7159 — the lookup will need adjusting.
• The PR also bundles a shared integrations/vcs/ module and comment posting logic. Those belong in GitLab integration: post comments on linked issues and MRs #7162 (comments), not here.

Acceptance criteria

• Issue state changes in GitLab update the linked feature flag's tags in Flagsmith
• MR state changes (opened, merged, closed) update the linked feature flag's tags in Flagsmith
• Webhooks are registered automatically — the user does not configure them manually in GitLab
• Emit structlog events for product telemetry (Epic: Open structured event pipeline for the backend #7012)