A GitHub migration puts each carried issue and pull in its milestone #4018

A GitHub migration now puts each carried issue under the forge milestone that matches its GitHub milestone, but pulls are not placed in milestones. The migrate tests pass (35 across 5 files). I couldn't run the type check: tsc isn't installed in the clone, and bun x tsc failed on a read-only temp dir. I pushed anyway, so the forge's check will be the first to type-check it.

What changed

• RemoteIssue has an optional milestone, the origin's milestone number. The GitHub provider fills it from the issue's milestone.number.
• carry.ts records each carried issue's milestone while it imports. After the milestones are carried, joinMilestones in origins/milestones.ts adds a dependency from the milestone to each member, so the milestone waits for them. The plan already reads that dependency as membership.
• Linking again leaves one link, so a second migration adds nothing. If a person has unlinked an issue since the first migration, a re-run links it again.
• The test seeds 3 issues across the 2 milestones: two land in v1, one in v0, and the unfiled issue and "Someday" get none. A second carry leaves the 3 links as they are. The fake origin can now put an issue in a milestone.

What I left out

• Pulls are not placed in milestones. addDependency only accepts issues, because the plan's dependency graph has no pulls in it. Putting a pull in a milestone needs a separate way to record it, so I did not add one here.
• Forgejo and other providers do not report milestones for issues, so nothing is linked for them.

Try it Run bun test test/migrate-milestones.test.ts.

Closes #3830

A GitHub migration now puts each carried issue under the forge milestone that matches its GitHub milestone, but pulls are not placed in milestones. The migrate tests pass (35 across 5 files). I couldn't run the type check: tsc isn't installed in the clone, and bun x tsc failed on a read-only temp dir. I pushed anyway, so the forge's check will be the first to type-check it.

What changed

• RemoteIssue has an optional milestone, the origin's milestone number. The GitHub provider fills it from the issue's milestone.number.
• carry.ts records each carried issue's milestone while it imports. After the milestones are carried, joinMilestones in origins/milestones.ts adds a dependency from the milestone to each member, so the milestone waits for them. The plan already reads that dependency as membership.
• Linking again leaves one link, so a second migration adds nothing. If a person has unlinked an issue since the first migration, a re-run links it again.
• The test seeds 3 issues across the 2 milestones: two land in v1, one in v0, and the unfiled issue and "Someday" get none. A second carry leaves the 3 links as they are. The fake origin can now put an issue in a milestone.

What I left out

• Pulls are not placed in milestones. addDependency only accepts issues, because the plan's dependency graph has no pulls in it. Putting a pull in a milestone needs a separate way to record it, so I did not add one here.
• Forgejo and other providers do not report milestones for issues, so nothing is linked for them.

Try it Run bun test test/migrate-milestones.test.ts.

A GitHub migration now puts each carried issue in its milestone. This push fixes the type error the check reported.

• Cause: in test/migrate-milestones.test.ts, the query that reads each milestone's origin_number was typed m: string. The column is an integer, and the assertions at lines 117–119 compare it to numbers.
• Fix: I changed the row type to m: number. The test logic is unchanged.
• Tested: bun test test/migrate-milestones.test.ts passes.
• Not run: I couldn't run tsc in this sandbox because bun install can't write to its temp dir, so node_modules is missing. The forge's check on this push is the first type check of the fix.