fix(github): unhandled transient GitHub states in merge/assignee retries (3 Sentry events)

[JSONbored]

Summary

Two low-volume but real GitHub API edge cases aren't handled gracefully: a merge racing an in-progress merge, and a secondary rate-limit hit during assignee retries.

Evidence (Sentry)

• GITTENSORY-1K — HttpError: Merge already in progress, 2 events, first seen 1 day before filing.
• GITTENSORY-1M — HttpError: API rate limit exceeded for installation ID 143010787, 1 event, culprit ensurePullRequestAssignee(server) — likely a downstream symptom of the same repeated-retry pressure described in the companion issue for GITTENSORY-1G (198 always-failing assignment attempts adding real request volume).

Requirements

1. Merge already in progress: this is a known, documented transient GitHub state (another merge request for the same PR is already being processed). Confirm whether the merge call site has any retry/backoff for this specific error, and add one if not — it should not surface as an unhandled error.
2. Rate-limit-during-assignee-retry: once GITTENSORY-1G's fix lands (stop retrying an operation that can never succeed), re-check whether this recurs at all — it may resolve as a side effect. If it persists independently, confirm the assignee path respects the same rate-limit backoff/retry conventions used elsewhere in src/github/.

Deliverables

• Confirm whether GITTENSORY-1G's fix alone resolves GITTENSORY-1M; note the finding either way.
• Add retry/backoff handling for "merge already in progress" if none exists, with a regression test.

[linear-code]

JSO-3620