GitHub bridge: full import leaves ~17% of issues with the wrong status and labels (v0.11.0) #1638

Summary

A full git bug bridge pull from a GitHub repository leaves a sizeable share of issues with the wrong status and
labels. It is deterministic: a second pull with --no-resume gives the identical result.

Environment

• git-bug v0.11.0 (Homebrew, darwin/arm64)
• Repository: a GitHub repo with 581 issues, many of them on a Projects (v2) board

Steps

git bug bridge new --name=github --target=github --owner=<owner> --project=<repo> --token=$TOKEN --non-interactive
git bug bridge pull github
git bug bug --format json   # compare status/labels/title with `gh issue list --state all --json number,state,labels,title`

Result

• 581 issues imported, no import errors in the output
• 96 issues have the wrong status (closed on GitHub, open in git-bug)
• 28 have the wrong label set, 1 has the wrong title
• git bug bridge pull github --no-resume changes nothing: the same 96 stay wrong

For one affected issue the pull log shows new issue, two changed label and two new comment lines, but no
changed status, although the issue's GitHub timeline has a ClosedEvent (and a RenamedTitleEvent) queried
on its own.

What I found so far

• Replaying the importer's query shape (issues(first: 40, orderBy: {field: CREATED_AT, direction: ASC}, filterBy: {since: …}) with nested timelineItems(first: 100)), GitHub reports a smaller totalCount for
  some issues than a direct issue(number: n) { timelineItems(first: 100) } query: 9 instead of 13 for one issue,
  15 instead of 18 for another. With issues(first: 5, …) the same issue reports 18. So the nested timeline
  in a large issue page is silently truncated, and the dropped items include ClosedEvents.
• That does not explain every case: at least one affected issue reports the same timeline count (10) both ways
  and still gets no status change. The affected issues all carry Projects v2 timeline items
  (AddedToProjectV2Event, ProjectV2ItemStatusChangedEvent), which the query's union fragments do not select;
  I have not confirmed whether that matters.
• Related, but a different cause: Github bridge import: Githubs ClosedEvents are incoherent. #609 (closed issues without any ClosedEvent).

Workaround

After each pull, compare every bug with the GitHub REST issue list and apply the missing status close/open,
label new/rm and title edit locally, then bridge push. Pushing a close for an issue that is already closed
is a no-op on GitHub, so this is safe to repeat.