Problem

When a .taskcluster.yml defines tasks with different taskGroupId values, the GitHub service only recorded tasks[0]'s taskGroupId in the github_builds table and only published taskGroupCreationRequested for that first group. All other task groups were invisible to GitHub checks and statuses — the build record was never created, so no status was ever posted.

What changed

services/github/src/handlers/job.js

The graphConfig.tasks processing block now:

1. Builds an ordered Map<taskGroupId, routes> over all tasks, keeping the routes of the first task in each group.
2. Creates one github_builds row per unique taskGroupId (parallel, like the hooks path).
3. Calls createTasks unchanged (still a single call with all tasks).
4. Calls cancelPreviousTaskGroups once with the first new build. Sibling builds from the same event share the same event_id and are already excluded by the existing event_id filter inside cancelPreviousTaskGroups, so no interface change was needed there.
5. Publishes taskGroupCreationRequested once per unique taskGroupId (mirroring the hooks code path).

No database schema or API changes are needed — github_builds already supports multiple rows per SHA with different task_group_id values, and downstream handlers (status.js, deprecatedStatus.js, taskGroupCreation.js) look up builds by taskGroupId and need no changes.

Test coverage

• New fixture valid-yaml-v1-multi-group.json: 3 tasks — task1 and task2 in group A, task3 in group B.
• multi-group yml creates one build record per unique taskGroupId — verifies 2 github_builds rows (one per group), both pending.
• multi-group yml publishes taskGroupCreationRequested once per unique group — verifies exactly 2 publishes, one per group ID.
• multi-group yml calls cancelPreviousTaskGroups once for pull_request — verifies the function is called exactly once regardless of group count.
• does not cancel sibling task groups from the same event (in cancelPreviousTaskGroups unit suite) — verifies that builds from the same event (same event_id) are not cancelled when cancelPreviousTaskGroups is called for one of them.

Maintainer note

I followed the hooks code path (job.js:335-392) as the structural model, which already publishes taskGroupCreationRequested once per hook. I'd welcome feedback on whether publishing once per unique taskGroupId is the right behaviour, or whether there are downstream consumers that expect a single publish per job event.

Fixes #8751