ci(cutover): no Closes listed twice, room for the worst case, the checkout pinned (D332)

From the second review:
- A PR whose merge commit main already has is not listed again. edge's tip at
  a cutover is often that PR's merge commit, and its merged_at can be a moment
  after the cut-off's committer date, so its issues would have had the next
  release's comment too.
- timeout-minutes 240: the worst case is about 200, and a timeout must never
  cut off the step that starts rust-carbon again.
- A test pins the checkout: edge, except on a dry dispatch that names code_ref.

Dry run (CI run 54, before these): every gate refused for the right reason.
Public Rust is still the 22 October build, which lacks the three fields edge
carries for November, and gates 1 to 4 each saw it; the panel key wrote to,
restarted and read rust-carbon; the live half ran 266 pass, 0 fail; nothing
was opened, edited, commented or merged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY

.gitea/workflows/cutover.yml

@@ -92,8 +92,9 @@ env:
 jobs:
   cutover:
     runs-on: ubuntu-latest
-    # Carbon's restart and navmesh, the live half (about an hour), the PR checks.
-    timeout-minutes: 180
+    # Carbon's restart and navmesh, the live half (about an hour), the PR checks: about 100 minutes, 200 at the
+    # worst. Room for that, so a timeout never cuts off the step that starts rust-carbon again.
+    timeout-minutes: 240
     env:
       WORK: ${{ github.workspace }}/cutover-work
       STAGING_WORK: ${{ github.workspace }}/cutover-staging