Make topic tabs accessible to screen readers

[rezabakhshilaktasaraei]

The topic tabs inside a forum chat (and the sender tabs in a channel's Direct Messages inbox) were invisible to screen readers: the tab buttons had no names, no list semantics and no keyboard access, so a blind user could not tell which topics exist, which one is active, or switch between them.

The tab strip is now a tab control - it is named tabs everywhere in the UI, so the screen reader calls it that too. Each tab is a named item (title with unread count, mention state and the pinned mark, updated as the badges change), the active one is reported as selected, and the strip is named "Topics" or "Direct Messages" with the right orientation for each position. In screen reader mode the strip gets one roving Tab stop on the active tab; arrows move focus between tabs (Up/Down when vertical, Left/Right when horizontal, Home/End for the edges) without switching - the browse-then-commit pattern for tabs whose panes load their content - Enter or Space activates, the context menu key opens the topic menu anchored on the tab (a mouse-invoked menu keeps opening at the cursor), and the focused tab is scrolled into view. Keyboard focus survives the frequent rebuilds of the strip on unread updates. The folders sidebar follows in #31176.

The position toggle button got an accessible name, with the current position reported in its description. It is also one persistent widget now, reused across mode switches instead of being recreated with the strip, so pressing it from the keyboard keeps focus on it without the screen reader re-announcing the button on every press. Sighted users are unaffected - the button is only focusable in screen reader mode.

The strip is created only once it is needed, long after the top bar, the list and the composer, so its Tab stops used to land at the end of the chain. The chat sections now keep their Tab chain in visual order (the lib_ui visual Tab order added for the chat list column), which places the strip at its reading-order position wherever it sits - left column, top or bottom - and follows it as the toggle moves it around. The one thing the container cannot see on its own is the roving stop moving between tabs deep inside the strip, so the slider tells it after each move; without that, a Tab entering the strip from outside would follow wiring to the previous stop. The composer inside a topic needed the same treatment: its buttons are created in an order unrelated to the row layout, so switching topics used to scramble their Tab order, and its send-as picker was missing its accessible name.

Needs desktop-app/lib_ui#348 for the PageTab button role.

Tested with NVDA on Windows 10 in a forum group with the tabs layout: browsing, activation, unread counts, context menus and cycling the tab bar through all three positions - after each move the next Tab finds the strip at its new place, and leaving the strip and Tabbing back in lands on the active tab - the arrows browse freely inside, but once focus leaves, the roving stop parks back on the current topic.