TUI command bar: interactive command/input line in the bottom section

[sunng87]

Goal

Replace the current static bottom footer (foot_area, src/tui.rs) with an interactive command bar — a single-line input box that doubles as the TUI command line. It has three responsibilities:

1. Slash/prompt commands — a prompt the user can type into to run TUI commands (e.g. :q, :clear, :set wrap, :set nofollow, :conn-history …). Enter executes; Esc cancels.
2. State indicator — keep the existing live follow / wrap (and any future) status badges shown by colour (green = on), as today.
3. Filter input — typing / enters filter editing (see Display filter subsystem: filter decoded messages by client, type, and keyword #13); the message view updates live as the user edits, and Esc/empty clears it.

Current state

The bottom section today is a 3-row bordered area laid out at src/tui.rs:235-238 (Constraint::Length(3)), rendered as a read-only Paragraph (:383-393) that hardcodes the help text and the follow/wrap colour badges. There is no text cursor, no input handling, and no concept of an input mode.

Relationship with keybindings (must address)

Adding a text input introduces a mode to the TUI. This is the core design point of the issue:

• Normal mode (default): keys drive the existing keybindings as today (j/k/PgUp/PgDn/g/G scroll, f follow, w wrap, c clear, q/Ctrl-C quit). Entering the command bar (:) or filter (/) switches to input mode.
• Input mode: keystrokes are captured as text for the bar/cursor — j, k, f, w, c must NOT trigger their normal keybindings while editing. Esc returns to normal mode (cancel), Enter executes the command and returns to normal mode.

Define and document the mode model explicitly, including:

• Which key enters input mode (: command, / filter) and how focus is indicated (visible cursor + mode hint, e.g. : or / prefix in the bar).
• Left/right arrow / Home/End / Backspace / Delete cursor editing inside the bar.
• That q/Ctrl-C should still quit from normal mode; decide whether Ctrl-C also cancels input mode.
• How the help/hint line coexists with the bar (e.g. show keybinding hints only in normal mode, or in a 1-line hint area above the bar).

Proposed layout

Keep the bottom region ~2-3 rows. One row is the input line (prompt + text + cursor); the other can be a compact status/hint line with the follow/wrap badges and short keybinding hints. The bar should be visibly focusable: a prompt glyph (: or /) and a real cursor.

Out of scope

• Autocomplete of command names (can be a follow-up).
• Persisting command history across runs.

Notes

• Depends on / pairs with Display filter subsystem: filter decoded messages by client, type, and keyword #13 (filter input is one entry point into the bar).
• The bar reads the same App state (follow, wrap) used by the current footer (src/tui.rs:106-125), so this is a render + input-mode change, not a data-model change.

[iPeluwa]

@sunng87 happy to pick this up