fix(palette): arm the first row when the palette opens

`ListState::new` starts with no selected row, and it only picks one when a
query *changes*. So opening the palette and pressing Return — the shortest
path through the feature — did nothing at all, and until the user typed or
pressed Down there was no row showing what Return was aimed at.

The delegate did think row 0 was selected (`selected: Some(IndexPath::
default())`), which is why this never showed up as a missing-state bug:
`selected_command()` answered correctly, but the highlight and the Confirm
event both come from `ListState`, which disagreed.

`build_list_with_delegate` now hands the list the delegate's own
`first_row()` — the one that skips empty sections — right after
construction, so all three palettes (root, plain, ssh-connect) open armed.

Verified on screen: ⌘P now highlights "New Tab" immediately, and Return
opens a tab instead of doing nothing.

src/ui/palette.rs

@@ -978,8 +978,17 @@ impl PaletteView {
         window: &mut Window,
         cx: &mut Context<Self>,
     ) -> Entity<ListState<PaletteDelegate>> {
+        let first = delegate.first_row();
         let list = cx.new(|cx| ListState::new(delegate, window, cx).searchable(true));
-        list.update(cx, |state, cx| state.focus(window, cx));
+        list.update(cx, |state, cx| {
+            // `ListState::new` starts with nothing selected, and it only picks a
+            // row once a query changes. Opening the palette and pressing Return
+            // therefore did nothing at all, and until then no row showed what
+            // Return was aimed at. Every palette anywhere else arms the first
+            // row on open.
+            state.set_selected_index(first, window, cx);
+            state.focus(window, cx);
+        });
         list
     }