Fan out GitHub events to two independent queues via github-exchange

Every valid GitHub delivery needs two things done to it: the raw-log/statistics/release-tracking write (saveGithubValidatedToDatabase()) and the OOP entity dispatch (GitHubEventHandler → *Repository). Those are two genuinely independent failure domains — a slow or erroring entity write shouldn’t stall or drop the raw log, and vice versa. Rather than one queue with one Worker doing both jobs, or the producer calling sendQueue() twice, Src/handlers/github.php publishes once to github-exchange (a fanout exchange, confirmed via the CloudAMQP management UI), bound to both the github and github-database Queues — RabbitMQ delivers an identical copy of the Queue Message to each. Each Queue is then consumed independently by its own Worker (service and database-service respectively), with its own Retry Cycle and error queue, so a failure in one pipeline never blocks or loses messages in the other.

Considered options

• One queue, one Worker doing both jobs — rejected: couples the entity-dispatch failure domain to the raw-log/release-tracking failure domain; a bug or slowdown in one now blocks the other.
• Producer calls sendQueue() twice (once per queue) — rejected: doubles publish work/risk in the request path, and every future GitHub producer (e.g. the hooks Worker’s replay path) would need to remember to double-publish too, instead of the fan-out being structural.