Problem
In flat/list view, `render_process_list()` (src/ui/imgui/imgui_process_list_view.cpp:369-416) sorts the displayed `rows` by whatever column/direction the user picked (`view_model_.process_list.sort_column`/`sort_ascending`).
But `ImGuiApp::get_visible_items()` (src/ui/imgui/imgui_input.cpp:37-60), used by `handle_keyboard_navigation()` for Up/Down/PageUp/PageDown/Home/End, does its own independent depth-first tree walk in list mode that does not apply the sort — it only flattens in tree/PID order.
Result: if the user sorts the list view by e.g. Memory descending, pressing Down moves the selection to whatever the next node is in raw traversal order, not the row visually below the current one in the sorted table.
Fix
The rendered row order (already computed once per frame in `render_process_list()`) should be the single source of truth consumed by painting, selection, scrolling, and keyboard navigation — rather than each maintaining its own independent traversal/sort.
Problem
In flat/list view, `render_process_list()` (src/ui/imgui/imgui_process_list_view.cpp:369-416) sorts the displayed `rows` by whatever column/direction the user picked (`view_model_.process_list.sort_column`/`sort_ascending`).
But `ImGuiApp::get_visible_items()` (src/ui/imgui/imgui_input.cpp:37-60), used by `handle_keyboard_navigation()` for Up/Down/PageUp/PageDown/Home/End, does its own independent depth-first tree walk in list mode that does not apply the sort — it only flattens in tree/PID order.
Result: if the user sorts the list view by e.g. Memory descending, pressing Down moves the selection to whatever the next node is in raw traversal order, not the row visually below the current one in the sorted table.
Fix
The rendered row order (already computed once per frame in `render_process_list()`) should be the single source of truth consumed by painting, selection, scrolling, and keyboard navigation — rather than each maintaining its own independent traversal/sort.