[Feature Request]: Webhook integration

Feature Description

Add webhook receiver support so codestrike can automatically trigger a review when a pull/merge request is opened or updated on GitHub, GitLab, Bitbucket, or Codeberg/Forgejo, instead of requiring someone to manually run codestrike review <pr-url>.

Use Case

As a developer/platform team, I want codestrike to review every new or updated pull request automatically as soon as it's opened, without a human or separate CI job invoking the CLI. Currently the only way to trigger a review is the manual review command with an explicit PR URL.

Related Area

HTTP server / webhooks (serve command)

Proposed Solution (Optional)

Building on top of the codestrike serve webservice (see linked serve-webservice issue), add per-provider webhook endpoints, e.g.:

• POST /webhooks/github — verify X-Hub-Signature-256 using a shared secret, parse pull_request events (opened, synchronize, reopened), extract owner/repo/PR number, and enqueue/run a review via the existing internal/review.Pipeline.
• POST /webhooks/gitlab — verify X-Gitlab-Token, parse Merge Request Hook events.
• POST /webhooks/bitbucket — verify signature/secret, parse pullrequest:created/pullrequest:updated events.
• POST /webhooks/codeberg (Forgejo/Gitea-compatible) — verify X-Hub-Signature-256, parse pull_request events.

Each handler should map its provider-specific payload to the existing scm.Client/review flow, reusing whichever scm.Client implementation matches the provider (see the separate Bitbucket/GitLab/Codeberg VCS integration issues — this issue assumes those clients exist or land alongside it). Consider a shared internal/webhook package with a common Event{Owner, Repo, PRNumber, Provider} type that all provider parsers normalize into, so the HTTP layer and pipeline invocation stay provider-agnostic.

Alternatives Considered (Optional)

No response

Additional Context (Optional)

Depends on the codestrike serve webservice existing first (separate issue). Signature verification secrets per provider will need new config/env vars (e.g. GITHUB_WEBHOOK_SECRET, GITLAB_WEBHOOK_SECRET), similar to how GITHUB_TOKEN is configured today.

Start with the codestrike serve webservice and the existing internal/review.Pipeline and scm.Client integrations mentioned in the issue. Define the provider event handling around the proposed internal/webhook package, accounting for the separate serve and VCS integration issues. Done means supported providers accept verified events and trigger reviews for the specified pull or merge request actions.