fix(tui): 16 hints tell users to run `gaia tui …`, which is not a command on either binary

[kovtcharov]

16 user-facing strings in the terminal hub tell people to run gaia tui …, which is not a command on either binary. The Python CLI has no top-level tui subcommand — only gaia mcp tui — and the Go binary ships as gaia-tui, whose root command is its own name. So the instruction fails whichever one the user has.

Found while fixing the adjacent naming defect in #2700, which corrected the generated usage lines (cobra now derives them from argv[0]). These 16 are hand-written strings that PR deliberately left alone, because fixing them spans four packages and needs a product decision first.

Verified on both cores installed on this machine:

$ ~/.gaia/venv/bin/gaia tui list          # 0.17.1
gaia: error: argument action: invalid choice: 'tui' (choose from prompt, chat,
talk, summarize, ... mcp, cache, init, install, uninstall)

$ .venv/bin/gaia tui list                 # 0.22.0
gaia: error: argument action: invalid choice: 'tui' (choose from prompt, chat,
browse, analyze, ... connectors, config, init, install, uninstall)

The worst of these is tui/internal/cli/agents.go:211, which asks the user to retype the line verbatim after an install is refused:

If you trust the publisher, re-run:
  gaia tui install <id> --trust

That is a dead end: the refusal is the only path to installing an unverified agent, and the command it hands you does not exist.

Which way to fix it

Two options, and the choice is a product call rather than a code one:

1. Add a top-level tui subparser to src/gaia/cli.py that forwards to the gaia-tui binary. Every string below then becomes true, the docs stay as written, and gaia remains the single entry point users learn. This is what the strings and docs/reference/cli.mdx already assume.
2. Rewrite the strings to the invoked binary name. internal/cli can read it directly; internal/catalog and internal/ui cannot import internal/cli without a cycle, so the name needs threading through or lifting into a small shared package.

Option 1 is less code and matches the documented story. Option 2 is honest about what actually ships today.

All 16 occurrences

tui/internal/cli/agents.go:72     No agents installed. Install one with `gaia tui install <id>`.
tui/internal/cli/agents.go:79     Run `gaia tui list` for versions and updates from the Agent Hub.
tui/internal/cli/agents.go:211    If you trust the publisher, re-run: gaia tui install %s --trust
tui/internal/cli/agents.go:289    `gaia tui run … && next-step`
tui/internal/cli/agents.go:341    the background service supervises (`gaia tui list`)
tui/internal/cli/agents.go:388    (none) — install one with `gaia tui install <id>`
tui/internal/cli/chat.go:42-43    Use `gaia tui chat --agent <id> --%s …` (see `gaia tui list` for ids)
tui/internal/cli/chat.go:66-68    Usage: gaia tui chat --agent email  (3 lines)
tui/internal/ui/app.go:261-262    see what the Agent Hub offers with `gaia tui list`, then `gaia tui install <id>`
tui/internal/ui/app.go:265        Install more with `gaia tui install <id>` (`gaia tui list` shows what is offered)
tui/internal/catalog/catalog.go:222   run an agent the Agent Hub publishes (`gaia tui list`)
tui/internal/catalog/hub.go:282       `gaia tui list --installed` still works meanwhile

tui/test/cli_run_test.go:190 asserts on "gaia tui list", so it currently pins the broken spelling and will need updating under either option.

Two adjacent things

• tui/Makefile:10,13 builds bin/gaia, so a contributor's dev binary now prints gaia in its usage — re-creating the exact PATH collision installer/scripts/install.sh documents as the reason the shipped name is gaia-tui. Building as bin/gaia-tui would also put the argv[0] path under CI.
• docs/reference/cli.mdx:2396-2430 teaches gaia tui … and says the source binary is tui/bin/gaia. Its note that "gaia tui install email and gaia install email are the same command" holds for neither shipped binary today.