[Bug]: remaining mouse-only controls in the html reporter and trace viewer #42323

Version

1.63.0-next (checked on main at 644132a)

Steps to reproduce

Same class of defect as #42310 and #42311, which just landed. These four were not covered by either
and are still reachable only with a mouse.

1. Open any html report and press Tab through the header. The settings gear never takes focus, so
   the theme dialog cannot be opened from the keyboard.
2. On a report with metadata, Tab towards the Metadata toggle above the file list. It is skipped,
   so the metadata section cannot be expanded.
3. Tab towards any @tag chip next to a test. Skipped, so tag filtering is mouse-only.
4. In the trace viewer with a time range selected, Tab towards Show all in the action list.
   Skipped. Same for the error/warning badge that reveals the console.

Expected behavior

Each takes focus and activates with Enter or Space, the same way tab strips do since #41434, chips
since #42149, and expandable titles and the image diff switcher since #42310 and #42311.

Actual behavior

Tab walks past all four.

1 and 2 declare role="button" and then cannot be focused, so assistive tech is told there is a
button that cannot be operated. 3 and 4 carry no role at all, so they are not announced as controls
in the first place.

Confirmed at runtime rather than only by reading the source. Mounting the headerView story and
querying the gear gives:

{"cls":"subnav-item","tag":"DIV","tabIndex":-1,"title":"Settings"}

tabIndex: -1 on a div, so Tab cannot reach it.

Additional context

Worth noting for 3: Label has an href branch that renders a real <a>, but LabelsClickView
(labels.tsx:70) calls <Label onClick={...} /> with no href, so the clickable tag chips always
take the bare-span branch. ProjectLink sitting right next to them in the same view is a real
anchor, which is what makes this read as an oversight rather than a choice.

For 4, actionList.tsx:164 already uses a real <button> via ToolbarButton for an adjacent
action, so the two plain divs beside it are inconsistent within the same file.

Happy to take this, and I would follow the pattern from #42310 exactly, including the
var(--vscode-focusBorder, var(--color-accent-fg)) fallback since the html reporter does not define
--vscode-focusBorder. That said, my previous two PRs on this class were closed with the CLA check
still pending, so if it is faster for someone on the team to just fix these, please do, no
attribution needed.

thanks for the two fixes that already landed, seeing how you structured titleSuffix in #42310 was
genuinely useful to read. sorry if I have mislabelled any of these four. freshman in college and
still getting the hang of this codebase :)

Environment

System:
  OS: macOS 26.5.2
  CPU: (10) arm64 Apple M4
Binaries:
  Node: 26.0.0
  npm: 11.12.1
npmPackages:
  playwright monorepo at main (1.63.0-next)