cross-review: roundごとのreply/resolve漏れをガードし、resolve-pr-commentsの返信例を修正する

[takemi-ohama]

背景

ndf:cross-review は Step 5 で /ndf:fix サブエージェントを起動し、各 round の修正対象 thread に reply 投稿 + resolveReviewThread、さらに PR レベル Summary コメントを投稿する契約になっています。

しかし実運用で、メインセッションが手動で修正・push して次 round に進めてしまうと、この Step 5 の reply/resolve がスキップされても state.py start-round / judge / merge-fix 側で止まらず、未解決 inline thread が残ったまま APPROVE まで到達できました。

実例: https://github.com/KK-Generation/project-trygroup-prd-customer/pull/147

問題

1. cross-review のドキュメントには round ごとの reply/resolve と最終スイープが必須と書かれているが、スクリプト上のガードが弱く、メインセッションが手順逸脱しても検知されない。
2. resolve-pr-comments/SKILL.md の REST 返信例が gh api ... -f in_reply_to=<comment_id> になっている。実行時に HTTP 422 になり、reply 投稿に失敗した。少なくとも typed field の -F in_reply_to=<comment_id>、または GraphQL の reply mutation を使う形に修正したい。
3. reply 失敗後に GraphQL resolve だけ成功すると、thread は resolved になるが「どの修正で対応したか」の inline reply が残らない。

提案

• cross-review に unresolved thread 数の検査を追加し、前 round の fix 結果が無い / unresolved が残っている状態で次 round に進む場合は明示的に fail させる。
• resolve-pr-comments に reply + resolve + verify を行う小さな script を追加し、最後に unresolved_count=0 を確認する。
• resolve-pr-comments/SKILL.md の返信例を -F in_reply_to=<comment_id> または GraphQL reply mutation に修正する。
• サンプルコマンドは set -e 前提にして、reply 失敗が resolve 成功で隠れないようにする。
• cross-review の final report 前に最終スイープ結果 remaining_open=0 を必須検証する。

期待する状態

• 各 REQUEST_CHANGES round 後に、修正済み thread へ reply が投稿され、resolve される。
• APPROVE 到達時点で unresolved thread が 0 件であることをツールが検証する。
• reply API の例が実行可能で、422 にならない。