A fork's "Take updates from <parent>" issue closes itself once its default branch holds the parent tip it was opened for #1482

Replaces #1473 (a person's ask, first #1303). Both runs declined with nothing to merge: main already contains forge-upstream's 979e19e, and forkRelation now reads ahead. The issue stayed open anyway, so the crew was handed work that was already done. That is the defect to fix.

Done looks like.

• [ ] When forkRelation (src/core/following.ts) for a fork with an open convergeTitle issue (src/crew/converge.ts) reads synced or ahead, so the parent's tip is an ancestor of the fork's default branch, that issue is closed with a comment naming the parent tip and the fork commit that holds it. It is checked on every push to the default branch and on the follow tick.
• [ ] No run is queued for a converge issue whose parent tip is already contained. A queued one is cancelled with the same comment.
• [ ] A test, named in GATE, makes a fork diverge, opens the converge issue, merges the parent by hand, and sees the issue closed with no run started. A second test shows a still-diverged fork keeps its issue open.
• [ ] On this forge, trevato/forge's own converge issue for 979e19e is closed by this code after it lands, not by hand.
• [ ] Before the pull, bunx tsc --noEmit, the new test and bun test test/check-list.test.ts pass in the sandbox.

Files. src/crew/converge.ts, src/core/following.ts (read only, if possible), a new test, scripts/gate.ts. Fits: mason.