[Accessibility]: Add proper navigation commands and cursor for screen-readers

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Description

I use OpenCode through the terminal with a screen reader, specifically NVDA, and I have configured the TUI to disable mouse interaction. However, OpenCode is currently very difficult to use with screen readers because the TUI does not provide sufficient information about the current selection or focus.

For example, when navigating through selectable options using the Up/Down arrow keys, I cannot reliably determine which option is currently selected. There is no visible cursor, highlight, or other clear indicator that communicates the current selection to a screen reader.

Other coding agents with terminal UIs, such as Claude Code, Codex, and Antigravity CLI, provide a much clearer indication of the currently selected option. For example, they use a > marker next to the currently focused item:

> Option 1
  Option 2
  Option 3

This kind of indicator is particularly useful for screen-reader users because it provides a textual representation of the current focus/selection rather than relying solely on visual highlighting or terminal cursor positioning.

In OpenCode, the lack of an equivalent indicator makes many interactive menus and selection interfaces extremely difficult or effectively impossible for me to use with a screen reader. The problem is not simply that the mouse is enabled; even with mouse interaction disabled through the TUI configuration, the interface does not expose enough information about focus and selection.

I would therefore like to request improved screen-reader accessibility throughout the TUI. In particular, it would be helpful if interactive elements exposed their current focus/selection in a way that terminal screen readers can detect, such as a textual > indicator, an accessible focus marker, or another equivalent mechanism.

Ideally, this should apply consistently to menus, dialogs, selection lists, and other interactive TUI components.

I would also appreciate accessibility-related configuration options where appropriate, so users can adapt the TUI to different screen readers and accessibility needs.