[Bug]: Changing the sidebar project filter keeps the old scroll offset, landing on an arbitrary part of the new list #27323

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Have enough threads that the sidebar list is taller than the viewport (All projects).
2. Scroll the sidebar down (e.g. ~1500px).
3. Open "Filter threads by project" and pick a single project whose list is shorter.
4. Switch the filter back to "All projects".

Expected behavior

Changing the project filter replaces the list, so the sidebar should start at the top of the new list. The top is where the most recently updated threads and the inbox are, which is what you want to see right after narrowing to a project.

If a navigation widens the scope to reveal the opened thread (resolveSidebarRouteReveal), that reveal should still take priority over the reset.

Resetting to the top seems the most natural choice to me, but I'm happy to defer to maintainers on the intended behavior. The main problem is that you currently land at the bottom of the list or at an arbitrary position.

Actual behavior

The old scrollTop is kept, and the browser only clamps it when the new list is shorter. Measured with a headless browser at a 1440×900 viewport:

After narrowing, you land at the bottom of the filtered list, on its oldest threads. After widening again, you land in an arbitrary middle position.

From reading main @ 8970a321:

• The scroll viewport is reused across scope changes. No key depends on the scope.
• Nothing writes scrollTop or calls scrollTo when the scope changes.
• Scroll anchoring is disabled ([overflow-anchor:none] in ui/sidebar.tsx).
• useActiveRowReveal only runs on route changes and mounts, not on filter changes.
• No test covers scroll position on a filter change.

This seems related in spirit to #27109, which scrolls the list to the picked thread after a search, but it covers a different trigger.

Impact

Minor bug or occasional failure

Version or commit

Desktop 0.1.2 (observed). The code paths were checked on main @ 8970a321.

Environment

macOS 26.6.2, T3 Code (Beta) desktop app 0.1.2

Workaround

Scroll to the top manually after changing the filter.

Notes

Reproduced with the Working section enabled (collapsed). The Working section is off by default in 0.1.2 and on by default on main. The same clamping applies in both cases, because the problem only depends on the list being taller than the viewport.