renderFileTree() clears its scroll container with box.innerHTML='' and rebuilds
every row. Detaching the rows collapses scrollHeight, so the browser clamps
scrollTop to 0 — every folder expand/collapse, breadcrumb nav, refresh, and
hidden-files toggle that re-runs the renderer teleported the reader to the top of
a long tree, losing their place (the dominant interaction in the panel).
Fix: capture box.scrollTop before the innerHTML='' wipe and restore it after the
normal render tail (after _renderTreeItems repaints and the container is tall
again). A plain scrollTop restore is sufficient and correct here — expand/collapse
insert or remove rows BELOW the clicked disclosure, so the clicked row keeps its
offset from the top; no getBoundingClientRect anchor delta is needed (that's only
for the prepend-above case in the chat messages list). The reporter's data-path
anchor sketch is deliberately NOT used: _renderTreeItems rows carry no data-path,
so that selector would match nothing.
The two early-return paths (no-workspace hides the box; empty-dir has nothing to
scroll) are left untouched — they legitimately reset. The restore guards only the
normal render tail. loadDir's two-render sequence (initial + post-expanded-dirs
prefetch) is handled correctly: each renderFileTree() call independently captures
then restores its own pre-wipe scrollTop across the await.
Test: tests/test_issue5657_filetree_scroll_preserve.py — static guards that the
capture precedes the wipe and the restore follows _renderTreeItems (per the
maintainer test plan; drops the getBoundingClientRect anchor assertion since the
fix deliberately doesn't use it). Fail-without-fix verified; 355 workspace-tree
regression tests green.
Closes#5657.
