Fixes two issues in the flat list view.

1. List view scrolls faster than tree view

The virtualized list rebuilt its visible-row DOM on every scroll event. Each scroll frame emptied and re-appended the visible rows, so the content appeared to move more than the wheel input warranted — perceived as "scrolling too fast" relative to the non-virtualized tree view.

Fix: raise VIRTUAL_THRESHOLD so the flat list renders all rows directly, matching the tree view rendering path and its scroll behavior.

Trade-off: this effectively disables virtual scrolling, so very large vaults (thousands of files) will render more DOM nodes. The VirtualList code is retained for a future fix that re-enables virtualization without the speed regression (e.g. DOM node reuse instead of empty-and-rebuild).

2. List position jumps when entering or exiting inline rename

Entering or exiting inline rename (also background vault-event rebuilds) called renderList, which emptied the container and rebuilt the DOM. Two causes made the list jump:

1. scrollTop was restored while the container was still empty, so the browser clamped it to 0 — the list flashed to the top / selected row.
2. input.focus() scrolls the focused row into view by default, fighting the restored position asynchronously.

Fix:

• Split renderList into renderListContent + a try/finally wrapper that restores scrollTop only after the new DOM exists (via VirtualList.scrollTo for the virtual path, direct assignment otherwise). Covers every return path.
• focus({ preventScroll: true }) so focusing the input no longer scrolls.
• Removed the now-redundant scrollTop save/restore in the manual-reorder handlers, which renderList now owns.

Verification

• npm run build (tsc + esbuild) ✅
• npm run lint (eslint) ✅
• npm test — 112 tests, 18 suites ✅
• Manually confirmed in Obsidian: list/tree scroll speed now match; rename start/cancel/commit keep list position unchanged.