tui: spike a vim layer — ':' command line, counts, motions (#9)

[citizen-123]

Spike for #9. The issue suggested building : commands plus counts/motions first and judging from there, so that is what this is — a working layer to try, not a commitment to full modality.

Everything here is confined to the traffic pane, so a count or a : can never reach a target app that is itself running vim. The left pane is untouched.

The : command line

The part of #9 that stands on its own, independent of modality — a home for actions that never earned a keybinding:

:filter host:api     :sort size        :export flagged
:curl  :resend  :flag  :w  :help  :q

Every command calls the same model method as its key, so :curl and c cannot diverge. The command table carries its name, help text, aliases, and handler on one record, so the help overlay renders from the dispatcher itself rather than a parallel list — the same principle as the keymap-driven help from #8, applied to commands.

Commands stay reachable when the matching key is unbound, which is rather the point of having a command line. That required scoping one existing help assertion to the keymap-derived sections.

Motions

Keys	Motion
{count}	repeat the next motion — 5j, 3k, 2}
gg / G	first / last flow
{count}G	jump to a row — 12G
} / {	next / previous host

Counts are a prefix and gg is a sequence, so neither is a single key the keymap can name — those are built into the pane. } and { are single keys, so they are ordinary rebindable bindings (flow.host-next / flow.host-prev), honouring #8's "a vim layer is a different keymap rather than a second dispatch path".

A pending count or a lone g renders in the traffic header, so a half-typed motion is never invisible; esc discards it. User bindings always win — the motion path only sees keys the keymap does not claim.

Also

• The help overlay grew ~17 rows and could scroll its own title off a short terminal (lipgloss.Place centres but does not clip). It now clips with a … N more lines hint. Pre-existing, but this change made it likely.
• Fixed the new tests' fixture: a zero textinput.Model has no blink context, so Focus() panics on it — inputs must come from their constructors, as New() does.

Judging it

Answering the issue's open questions from having built it:

• Mode or default? Nothing here needs a mode. Counts, gg/G, }/{ and : all coexist with the existing plain keys, and there is still one dispatch path. The maintenance cost the issue worried about did not materialise, because none of this is a second input model — it is a prefix, two sequences, two bindings, and a command line.
• What would need a mode is the rest of the issue: dd/yy operators, and normal/insert in the editor and repeater. Operators need a pending-operator state, and an insert mode means the editor stops being always-insert. That is where two divergent input paths start, and it is a separate decision.
• : earns its place regardless. It pairs with Advanced filter syntax in the flow list #12 as the issue predicted — :filter and / already share a grammar here.

Suggest merging this and deciding operators/insert-mode separately, rather than treating #9 as one all-or-nothing change.

Testing

go build ./..., go vet ./..., go test ./... all pass; -race clean on tui and config. New tests cover counted motions, gg/G/{count}G, host jumps (including empty list, clamping, and no-wrap at both ends), esc discarding a count, alias resolution, and command-table hygiene (no duplicate name/alias, every entry has a handler and a description).

Docs: docs/keybindings.md gains motion and command sections; docs/configuration.md lists the two new actions and notes why motions and : are the one part of the overlay that is not keymap-derived.

Closes #9 as an exploration — the follow-on operator/insert-mode question is left open.