Filter by comm name or path

[shinagawa-web]

In the TUI, allow the user to narrow the captured traffic list by typing a search term.

Motivation

PID filtering is impractical: the user doesn't know the PID until traffic is already flowing. Filtering by human-readable identifiers — comm name or request path — covers the real use cases:

• "Show only nginx traffic" → filter by comm nginx
• "Show only requests to /api/..." → filter by path prefix

Proposed UX

Press / to enter filter mode. Type a term; the row list narrows in real time to rows where comm or path contains the term (case-insensitive). Press Esc to clear the filter and return to the full list.

Scope

• / key opens an inline filter input at the bottom of the table
• Rows are filtered live as the user types (comm or path substring match)
• Esc clears the filter
• Follow mode continues to work while a filter is active (new rows that don't match are hidden)
• Unit tests for filter logic

[shinagawa-web]

Reconsidering the scope of this issue.

PID filtering has a fundamental UX problem: the user doesn't know the PID until traffic is already flowing in the TUI. That means filtering by PID upfront (e.g. --pid flag at startup) is impractical, and filtering after the fact adds little value since the rows are already visible.

A more useful alternative would be text search by comm name (e.g. pressing / to enter a search term like nginx). Process names are human-readable, stable across restarts, and the user can identify them without looking up a PID first.

Suggest either closing this in favor of a comm/path search issue, or reframing the scope accordingly.