bug: Duplicate processing of pull_request synchronize webhooks

Description

Summary

The GitHub pull_request synchronize webhook appears to be processed twice.

The webhook handler directly calls handlePullRequestSynchronize() for pull_request synchronize events and then subsequently queues the same webhook payload using addWebhookJob().

This can cause the same pull-request synchronization event to be processed both synchronously and asynchronously.

Expected behavior

A webhook delivery should be processed exactly once through a single processing path.

The request handler should either:

• process the event synchronously, or
• enqueue it for asynchronous processing.

It should not execute the processing logic and then enqueue the same event again.

Actual behavior

For a pull_request event with:

action = synchronize

the handler executes:

await handlePullRequestSynchronize(parsed.payload);

and later executes:

await addWebhookJob(
  {
    payload: parsed.payload,
    deliveryId,
    event,
  },
  { jobId: webhookJobId(deliveryId) },
);

Therefore, the same delivery enters both processing paths.

handlePullRequestSynchronize() already performs database operations, retrieves changed files from GitHub, scans dependency manifests, and creates vulnerability findings before the queue job is added.

Steps to reproduce

1. Configure SecureFlow with a valid GitHub webhook.
2. Create a Pull Request in a repository monitored by SecureFlow.
3. Push another commit to the Pull Request to trigger a pull_request.synchronize webhook.
4. Inspect the SecureFlow application logs and database activity.
5. Observe that handlePullRequestSynchronize() executes before the webhook job is queued.
6. The queued job can subsequently process the same webhook delivery again.

Screenshots / Logs

[PR_SYNC] New code pushed to PR #... 
[SBOM] Checking ... files for manifests...
[SBOM] Found ... vulnerabilities...

... webhook job queued for the same delivery ID ...

Environment

• SecureFlow version/commit:
• Deployment method:
• Node version:
• OS:

Additional context

The webhook route currently performs:

verify webhook
      ↓
handlePullRequestSynchronize()
      ↓
addWebhookJob()
      ↓
worker processing

This creates two possible processing paths for the same delivery.

The duplicate processing can result in unnecessary GitHub API calls, repeated dependency scanning, duplicate database work, and potentially duplicate findings or other side effects depending on the worker implementation.

A cleaner design would be to make the webhook endpoint responsible only for validation and queueing, with the worker being the single owner of webhook processing.

Alternatively, if synchronous processing is intentional, the event should not subsequently be queued for processing again.