feat(spectator): 観戦者が任意のタイミングで途中参加できるようにする

[progre]

概要

これまで観戦者は、難易度選択画面（カード未選択時）でしか参加できませんでした。この PR により、観戦者はいつ接続しても観戦を始められるようになります。

仕組み

• 接続時: ホストは観戦者にプレイヤー名と設定を送ります。
• 選択画面で接続した場合: 観戦者は、難易度選択画面またはキャラクター選択画面で、キャラクターを決定せずに待ちます。
  • ホストは試合開始時（キャラクター選択画面から読み込み画面に移ったとき）に、難易度、両プレイヤーのキャラクター・カード、乱数シードを送ります（InitGame）。
  • 観戦者は難易度・キャラクターのカーソル・カードを合わせ、一致していることを確認してから両プレイヤーを決定します。読み込み画面に移った時点で乱数シードを設定し、以降はホストの試合中の入力を再生します。
• 試合中に接続した場合: ホストは、進行中の試合の InitGame とそれ以降の入力の記録をまとめて送ります（記録は1試合分で、試合ごとに作り直します）。観戦者は試合の最初から早送りで追いかけます。
• ホストとの差の解消: 観戦者の試合がホストより遅れて始まった分は、溜まった入力を no_wait で早送りして追いつきます。
• ずれたときの扱い:
  • 観戦者の試合中にホストの次の試合が始まった場合は、今の試合を打ち切り、次の試合から同期し直します。
  • 試合開始時の状態を合わせられない場合や、合わせた結果が一致しない場合は、観戦を終了します。
• 観戦用のデータチャネルプロトコル: JUNOWEN/1.2 に上げ、旧バージョンの観戦者は接続の時点で拒否します。対戦は JUNOWEN/1.1 のままで、互換性を保ちます。

主な変更

• junowen-lib: PeerConnection / SignalingSocket / ChannelSocket で、プロトコルを用途ごとに指定できるようにしました（BATTLE_PROTOCOL / SPECTATOR_PROTOCOL）。
• ホスト側（SpectatorHostState）:
  • 試合開始を待つ観戦者と、観戦中の観戦者を分けて管理するようにしました。
  • 進行中の試合の記録（GameLog）を追加しました。
  • 選択画面の入力は観戦者に送らなくなりました。
• 観戦者側:
  • 状態遷移を Prepare → Standby → GameLoading → Game → BackToSelect → Standby にしました。
  • 待機中は、キーボードの ESC か P1 の PAUSE で中断できます。

確認状況

• i686-pc-windows-msvc ターゲットで cargo check（ワークスペース全体）/ clippy / fmt が通ることを確認しました。clippy の警告は main より減っています。
• 実機での動作は未確認です。 特に次の点の確認をお願いします。
  1. 読み込み画面に移った時点で、selection.pX.character/card/difficulty が確定した値になっているか
  2. キャラクター選択画面で、カーソル（Menu::pX_cursor）とカード（selection.pX.card）を書き込んで反映されるか。カーソルの値がキャラクター番号と一致するか
  3. 観戦者がキャラクター選択画面で難易度の違いを検知したとき、PAUSE の入力で難易度選択画面に戻れるか
  4. 読み込み画面に移った最初のフレームで乱数シードを設定して、ホストと同期するか
  5. 試合中に no_wait で早送りしても問題ないか。また、試合中に接続した観戦者がホストに追いつけるか

🤖 Generated with Claude Code

https://claude.ai/code/session_011qhChXocxUoUmMqt9cLXQa

[progre]

可読性の観点でいくつか気になった点をインラインコメントしました。機能自体は成立していそうですが、状態管理（initializing_state）と sync_screen/ready の意味の乖離が特に追いにくいと感じたポイントです。

---

Generated by Claude Code

[progre]

設計レビュー

方針は妥当です。 「同期ポイントの状態＋それ以降の入力ログを再生する」方式は、既存の決定論的な入力同期と噛み合っており、通信メッセージの型も新設せずに済んでいます。送信経路を broadcast() にまとめて記録漏れを防いでいる点、initializing_state を enum にした点も良い改善です。

一方で、増えた複雑性は観戦者側で「キャラクター選択画面に合わせる」処理に集中しており、整理の余地があります。指摘は重要度の高い順に次のとおりです（詳細は各インラインコメントを参照してください）。

1. pending_sessions は実質的に到達しない経路で、関連する表示やカウントも不要なコードになっている
2. 同期ポイントまで移動する処理を SpectatorSelect から独立した状態に切り出す
3. 入力ログの記録量に上限がない（コメントの「1 対戦分」は実態と合わない）
4. 対戦中の F1 受け付けは不要で、差分を減らせる
5. Screen::Game の unimplemented!() と、旧バージョンの観戦者との互換性
6. （軽微）buffered_len の名前と副作用が一致していない

PR 本文に挙がっている実機での確認事項（カード選択状態の再現、入力タイミングの一致、no_wait による早送り）は、コードからは判断できません。2 の方針はその確認結果を踏まえて決めるのがよいと思います。

---

Generated by Claude Code

[progre]

再レビュー（95f9cd2）

前回の指摘6件は、f8b7908 ですべて対応済みです。その後、方式が「試合開始時に InitGame を送る」形に変わったので、新しい方式を前提に見直しました。

設計は大きく簡素になり、方針として妥当です。

• 入力ログ、同期ポイント、記録量の上限、進行段階の推定がすべてなくなりました。
• ホスト側は「試合開始を待つ観戦者」と「観戦中の観戦者」の2つのリストを持つだけになりました。
• 観戦者側の同期処理は spectator_standby.rs の1か所に集まっています。
• プロトコルの分け方は SignalingSocket::protocol() の既定実装で済ませており、変更が最小限です。

変更ファイルは26に増えましたが、その多くはプロトコルを渡すための配線です。ロジックの複雑性は前回より下がっています。

新たな指摘は次のとおりです（詳細は各インラインコメントを参照してください）。

1. 古い方式を前提にしたコメントが4か所に残っている
2. 状態が一致しないときは warn ログを出すだけで、一致が成立しないと待機画面から抜け出せない
3. 試合中に InitGame を受け取るとセッションが切れる。次の試合から同期し直す形にできる
4. （軽微）待機中にゲームパッドから抜けられない
5. （軽微）try_recv_init_game にリセットの副作用がある

「試合途中からの観戦」については、実装側からの質問（ラウンド間で持ち越す状態があるか）が回答待ちのままです。

---

Generated by Claude Code

[progre]

再々レビュー（0fe6dbd）

前回の指摘5件への対応を確認しました。

指摘	結果
古いコメント	解決。4か所とも修正済み
不一致時・待機上限	方針は同意。軽微な追記あり（スレッドを未解決に戻しました）
試合中の InitGame	方針は同意。簡素化の提案を追記（スレッドを未解決に戻しました）
ゲームパッドで中断	解決
try_recv_init_game の副作用	解決

設計上の大きな問題はもうありません。未解決に戻した2件は、どちらも簡素化や読みやすさに関するもので、マージを止めるほどの内容ではありません。

PR 本文にある実機での確認事項は、引き続き確認をお願いします。

---

Generated by Claude Code

[progre]

何を根拠に位置を変えたのですか？（+94h は自明なので書かないでください）