GUI: Improve Tree accessibility with TreeGrid navigation

[ndarilek]

Update Tree accessibility to follow the WAI-ARIA treegrid pattern:

Keyboard navigation changes:

• Right arrow on cell 0: Expand collapsed row, or move to next cell
• Left arrow on cell 0: Collapse expanded row, or stop if collapsed
• Right/Left arrows: Navigate between cells and buttons within a row
• Tab/Shift-Tab: Move between focusable elements (buttons, editable cells)
  in the current row, then exit tree when no more focusable elements
• Up/Down arrows: Navigate between rows, maintaining column position
• Arrow keys never exit the tree (always accepted)

Focus model:

• Cell-focused navigation (no row-level focus) for screen reader compatibility

Accessibility improvements:

• Use ROLE_TREE_GRID for multi-column trees
• Use ROLE_ROW for tree items (instead of ROLE_TREE_ITEM)
• Use ROLE_CELL for individual column cells
• Use ROLE_COLUMN_HEADER for column titles
• Hide column headers from accessibility tree when not visible
• Parent buttons to row element (not cell) to prevent announcement clutter
• Only set expanded/collapsed state on items with children
• Set active_descendant on tree grid for screen reader focus tracking

Reference: https://www.w3.org/WAI/ARIA/apg/patterns/treegrid/

[bruvzg]

New values should be added to the end of the list to avoid compatibility breaking.

[ndarilek]

This is ready for review. Open to feedback. I recognize it changes a lot regarding how trees are navigated via arrows/tab, but it seemed a bit messy and inconsistent before.

Originally I went with a more conservative interpretation of the treegrid pattern that just used arrows in the trees rather than tabbing between controls. I discovered, though, that this made discovery of associated buttons very difficult for me as a screen reader user. I'm used to tabbing through interfaces, and on numerous occasions completely missed that there were buttons to the right of tree items. Claude Code had to tell me where lots of functionality I needed was, at which point I realized we needed the stricter approach. I do, however, wonder if shift-tab should navigate backwards through the tree for consistency, which it currently doesn't as per strict adherence to the pattern.