Skip transfer event handling when the group is gone

🤖 AI wrote this code from my instructions.

Unreviewed AI output often lands on reviewers and costs them time.
This MR is human verified: I read the full diff and ran the tests myself, because your time is as valuable as mine.

What does this MR do and why?

Vulnerabilities::ProcessTransferEventsWorker#project_ids looks the group up with find_by_id, then reads group.id on the next line with no guard. When the group is deleted between the event being published and the worker running, that raises NoMethodError: undefined method 'id' for nil. Sidekiq then retries until the job dies.

Three workers subscribe to Groups::GroupTransferedEvent, and the other two already guard this:

Worker	Guard
Sbom::ProcessTransferEventsWorker	return [] unless group
Vulnerabilities::NamespaceHistoricalStatistics::ProcessTransferEventsWorker	return unless group
Vulnerabilities::ProcessTransferEventsWorker	none

This adds the same guard. It returns [] rather than nil, matching the Sbom worker, because the caller does project_ids(event).each_slice(...).

The impact is error noise and retry churn, not lost data. If the group is gone its projects are going too, so the skipped work is moot.

References

None.

How to set up and validate locally

bundle exec rspec ee/spec/workers/vulnerabilities/process_transfer_events_worker_spec.rb

13 examples, 0 failures. Reverting the guard alone fails the new example with NoMethodError: undefined method 'id' for nil.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.