fix(room): a lagging participant goes permanently deaf

[smileygames]

観測

配送ポンプが broadcast の lag で終了し、以後その参加者へ何も届かなくなる。ソケットは開いたままなので、画面にも名簿にも異常が出ない。

serve_participant の pump は次の形をしている（src-tauri/src/room.rs）。

while let Ok(fanout) = from_room.recv().await {
    if fanout.origin == own_origin { continue; }
    if sink.send(Message::Text(fanout.frame.into())).await.is_err() { break; }
}

tokio::sync::broadcast::Receiver::recv は、受信が容量（256）ぶん遅れたとき Err(RecvError::Lagged(n)) を返す。while let Ok(..) はこれで抜ける。Lagged の後も receiver 自体は使えるため、本来は取りこぼした件数を記録して継続できる。現状は恒久的に離脱する。

Err(RecvError::Closed) との区別も無い。

前提

• feat(room): one post frame, so a participant is a participant #39 以前から同じ形であり、今回の投稿モデル統一で入ったものではない。ただし feat(room): one post frame, so a participant is a participant #39 で全参加者への fan-out が本格的に動き出すため、露出する確率は上がる。
• 発生条件は、ある参加者の送信が 256 件ぶん滞留すること。エージェントの応答が詰まる、ソケットの書き込みが遅い、といった状況で起こりうる。
• 掲示板として常時複数の参加者が座る前提では、片方が黙ったまま生きているように見える状態は診断が難しい。

制約

• Lagged と Closed を分けて扱う。Lagged は継続、Closed は離脱。
• 取りこぼしは沈黙させない。件数を stderr へ出す。部屋の発言が落ちたことは参加者側から観測できないため、ログが唯一の手がかりになる。
• 落ちた発言の再送は行わない。部屋は履歴を持たない設計であり、ここで持たせない。

対象ファイル

• src-tauri/src/room.rs

完了条件

• lag した参加者が、その後の発言を受け取り続ける。
• 取りこぼした件数が stderr に出る。
• ソケットが閉じたときは従来どおり離脱し、名簿から外れる。

関連

• feat(room): one post frame, so a participant is a participant #39 — 投稿モデルの統一。この形はそれ以前からあるが、露出はこちらで上がる。

[smileygames]

#47（PR #52、protocol 4）のマージにより、この欠陥の到達しやすさが上がりました。本文の変更はありません。

post_result フレームが追加され、投稿ごとに部屋 → 送信者へ 1 フレーム返ります。fan-out と合わせて broadcast のトラフィックがおよそ倍になり、broadcast::channel(256) の容量に対する滞留の余地がその分狭まりました。

該当箇所は本文のとおり serve_participant の pump です（src-tauri/src/room.rs）。while let Ok(fanout) = from_room.recv().await が RecvError::Lagged で抜ける形は #52 でも変わっていません。

影響が一段重くなっています。 #47 以前、pump の離脱は「その参加者に発言が届かなくなる」ことでした。#52 以降は post_result も同じ pump を通るため、離脱した参加者は 自分の投稿の結果を受け取れなくなります。サイドカー側は 15 秒のタイムアウト（POST_RESULT_TIMEOUT）で unconfirmed を返すため固まりはしませんが、以後その参加者の発言はすべて 15 秒待たされたうえで結果不明になります。

完了条件は本文のままで足ります。Lagged を継続、Closed を離脱として扱えば、post_result の経路も同時に直ります。