fix(autopilot): sync GitHub issue close state with Project Close (#843)

[smalruby3-editor-bot]

Summary

merge 済みでも GitHub issue の close 状態と Project の Close ステータスが乖離する 2 方向の不整合を整合させる（非デフォルト base 宛て PR / EPIC で顕在化。#738 / #839 / #840 で実際に発生し手動整合した）。

Changes Made

Fix A — merge-progression が GitHub issue も close する

• project.closeIssue(repo, issue, token) を新設（gh issue close。既に closed なら no-op で冪等）。
• applyMergeProgression が leaf を Close へ前進させたら GitHub issue も明示 close。非デフォルト base 宛て PR（EPIC サブ）で Closes #N 自動 close が効かない件に対応。
• 同 tick の closed-reconcile が二重処理しないよう、merge 後に in-memory item.status を Close に反映。

Fix B — 「closed issue → Project Status=Close」整合パス

• project.listClosedIssueNumbers(repo, token) を新設（gh issue list --state closed --json number → Set。gh project item-list の content には state が無いため別経路）。
• 純粋関数 selectClosedToReconcile(items, closedSet): issue が closed かつ Project Status が Close/Done(終端) でない item を返す（EPIC も対象）。
• applyClosedReconcile を tick に追加: 対象に Status=Close + AI Status クリアを適用。running 中は触らない。list 取得失敗・個別失敗は他を止めない。

両 Fix で「GitHub issue 状態 ⇄ Project Close」が双方向に整合する。

Test Coverage

• selectClosedToReconcile / TERMINAL_STATUSES の node:test（EPIC 包含・終端 skip・配列/Set 受理・空入力）。
• listClosedIssueNumbers / closeIssue の I/O テスト（gh 引数注入）。
• applyMergeProgression が GitHub issue も close すること / gh close 失敗がループを止めないこと。
• applyClosedReconcile（EPIC 含む整合・running skip・list 失敗の no-op・個別失敗の隔離）。
• cd tools/autopilot && node --test → 139 tests, 0 fail。

Related Issues

Closes #843

[smalruby3-editor-bot]

🤖 autopilot status

field	value
Status	Review
AI Status	—
HITL	Yes
Size	middle

Linked issue #843. Maintained by autopilot (single writer); do not edit.

[smalruby3-editor-bot]

🤖 autopilot 敵対的レビュー（#843）

実装を別視点で批判的にレビューしました。重大な問題なし。 自分で 1 件対応済み、人間レビューへ渡します。

確認した点（良好）

• 設計が既存パターンに整合（純粋関数=phases.js / I/O=project.js / オーケストレーション=daemon.js、deps injection）。
• 冪等性が二重に担保: Fix A は applyIntents 後に in-memory item.status='Close' を立て、同 tick の closed-reconcile が TERMINAL_STATUSES で除外 → 二重処理しない。EPIC は merge-progression 対象外なので Fix B のみが処理 → 経路の重複なし。
• item.issue / listClosedIssueNumbers ともに数値なので Set.has 一致（型ズレなし）。
• dispatch は最初の await 前に同期で state.running.set するため、同 tick で dispatch した issue は reconcile の running ガードで保護される（競合なし）。
• ユニットテスト 8 件追加（happy / error / 冪等 / EPIC 含む / running skip / array・Set 入力）、全 139 件 green。

自分で対応（1 件）

• docs/autopilot/README.md の merge-progression 節に Fix A（明示 gh issue close） と Fix B（closed-issue → Project Close 整合） を追記（DoD: 挙動変更時の docs 更新）。

非ブロッキングな指摘（人間の判断に委ねます）

1. listClosedIssueNumbers の --limit 1000: closed issue が 1000 を超えると gh issue list のデフォルトソート（作成日降順）から漏れた古い issue を取りこぼす可能性。現状リポジトリは ~800 台で問題ないが、将来のスケール時に注意。
2. 失敗した gh issue close の再試行なし: closeIssue が一時的に失敗しても Project は既に Close（merge-progression が冪等で再発火しない）かつ GitHub は open のまま closedSet に入らないため、自己回復しない。Fix B は GitHub→Project の片方向整合なので Project→GitHub の取りこぼしは対象外。発生頻度は低くプレ既存の挙動に近いため scope 外と判断。