Proposal: read-only interactive TUI

## Summary
Add a keyboard-first interactive terminal UI to `docket`, inspired by tools like `lazygit`, while keeping all existing scripted and `--json` flows intact.
## Why
`docket` is already strong for scripting and direct commands, but human browsing is still command-by-command. A read-only TUI would make it faster to inspect work, switch between views, and understand issue state without losing the current CLI model.
The goal is not to replace the existing command surface for automation. The goal is to add a human-friendly read mode.
## Current MVP
A first read-only MVP already exists locally with:
- `docket ui`
- default `list` view
- `board` view
- synced detail pane
- keyboard navigation
- targeted regression coverage for a board-view terminal input bug
## Proposed Direction
Treat `docket ui` as the default human-facing read experience over time, while keeping command-based and `--json` flows stable.
Planned read-only expansion areas:
- `next`
- `plan`
- `stats`
- `config`
- `version`
- issue activity/log view
- issue graph/dependency view
- issue link list
- issue file list
- comments/files/relations/activity subviews
- label browser
- vote list / proposal detail / result
- filters, sort, limits, refresh, navigation palette
## Non-Goals
- No write flows in this phase
- No replacement of existing JSON/script workflows
- No forceful switch away from current CLI commands
## Questions For Maintainers
1. Do you want `docket ui` in the project at all?
2. If yes, should we continue expanding it as a read-only TUI first?
3. If yes, should it stay opt-in as `docket ui`, or is the long-term direction to make it the default human mode?