* Add a pinned sticky group header to GroupedVirtualizedList
Section-header rows pin natively with `position: sticky`, applied via a
`components.Item` wrapper that detects header entries. Consecutive stuck
headers stack in DOM order, giving compositor-driven cover/reveal: the
incoming header covers the current one on scroll-down and slides off to
reveal the previous on scroll-up.
Because the flat virtualizer unmounts off-screen rows, a sticky header
row vanishes once a tall section scrolls past the overscan window. An
always-mounted overlay outside the item stream backstops this, keeping
the current section's header pinned; a mounted real header row sits over
it for an invisible hand-off. The current section is tracked from the
rendered items' offsets and live scrollTop on Virtuoso's onScroll.
`scrollPaddingTop` on the useVirtualizedList hook lands keyboard-focused
items below the pinned header via Virtuoso's calculateViewLocation.
Signed-off-by: David Langley <langley.dave@gmail.com>
* Show a sticky section header in the room list
VirtualizedRoomListView renders the current section's header into the
pinned overlay via RoomListStickySectionHeaderView, which reuses
RoomListSectionHeaderContent so the chevron, title, notification badge
and section menu stay identical to the real header. The overlay is
mouse-interactive but `aria-hidden` and out of the tab order; the real
header rows keep all keyboard, screen-reader and drag-and-drop duties.
Headers use a uniform 44px height so a covering header fully covers the
one behind it, and an opaque background so stacked stuck headers don't
show through each other. Snapshot regenerated.
Signed-off-by: David Langley <langley.dave@gmail.com>
* Stop enforcing 44px height
* Clarify sticky-header z-index layering
Only the relative order of the room-list sticky stack matters (room rows <
overlay backstop < real sticky header rows), so use 1/2 instead of 10/11 and
spell out the ordering in comments. Explain why the overlay's opaque fill needs
z-index: -1 (absolutely-positioned, so it would otherwise paint over the header
content). No behavioural change.
---------
Signed-off-by: David Langley <langley.dave@gmail.com>