docs: close the card list's open questions, and record a navigation defect

Both items the spec left open are settled, and one of them turned out to be a
defect rather than the addition it was filed as.

Item 20 deferred "move between messages without returning to the list" as an
addition on top. It is a repair: next_thread and prev_thread are
selectRow(current.row() + 1), and a tree numbers rows per parent, so from the
last reply of an expanded thread row+1 names a sibling that does not exist and
the action silently does nothing. rowCount() with no argument counts top-level
threads, compounding it. Recorded as item 60, since it exists on the branch
whether or not the card list is built, and it is a fresh instance of the exact
rule that branch's own commit message states.

The user asked for arrow keys to skip within a thread and Shift+arrows to skip
between threads, scoped so the keys still work normally in the message pane,
menus and entry bars. Two findings changed the shape of that:

  - Up/Down need no binding and no code. QTreeView's built-in navigation walks
    VISIBLE rows, so it already steps into an expanded thread's replies, and
    being the view's own key handling rather than a shortcut it is inert
    whenever focus is elsewhere. The requested focus behaviour is automatic.
  - Arrow keys must never become keymap actions. Every action is a QAction with
    WindowShortcut, dispatched before the focused widget sees the key, and Qt
    withholds only plain LETTERS from editable widgets. Return already proved
    this by breaking the query bar and needing a per-widget ShortcutOverride
    filter scoped to one widget and one key. Up as a window shortcut would break
    the query bar, the tag dialog and the web view at once.

Shift+Up/Down was rejected for thread-jumping: it is the built-in
extend-selection that multi-row tagging and item 20's action scope depend on.
Alt+Up/Down instead, verified free across the whole keymap.

The way back to a whole thread after clicking a reply is the root card, which is
always visible above its replies. Escape is deliberately not overloaded, since
it already means clear-selection with clear-pane on Shift+Escape, and a third
meaning is the half-an-action problem item 50 exists to fix.

The remaining open item is only whether the message pane should change to match,
which stays out of scope: this spec is the left pane.

0 files changed, 0 insertions, 0 deletions