Scroll position persists across tab changes, leaving non-scrollable views cut off #534

When a user scrolls down inside a scrollable tab (such as "Advanced Features") and switches to a non-scrollable tab (such as "Home"), the view retains the previous vertical scroll offset.

Because the target tab has no scroll container or overflow content, the user cannot scroll back up. This leaves the interface stuck at the inherited offset, hiding the top portion of the view.

Steps to reproduce

1. Open a tab with scrollable content (for example, "Advanced Features").

2. Scroll down past the top of the page.

3. Switch directly to a non-scrollable tab (such as "Home").

Expected behavior
Switching tabs should either reset the scroll offset to (0, 0) or keep an isolated scroll state per tab. Non-scrollable tabs should always render starting from the top.

Actual behavior
The target tab renders at the previous tab's scroll position. Because scrolling is disabled or unsupported on that view, the user cannot scroll back up to recover the view.