Fix command palette over focused scratchpad

The stdin loop's scratchpad-input branch ran before the palette branch
and silently dropped every byte except a handful of app-level chords,
so palette typing and Esc never reached the palette while a pad was
focused. Skip the pad-input branch whenever st.palette != nil.

closePalette also called repaintFocused() on cancel / no-op action
paths, which paints the empty focused-child slot (focusedID == "" while
a pad is focused) and leaves the palette's top border drawn over the
pad. Route those branches through a restoreView helper that picks
repaintFocusedPad when a pad is focused.

Switching from a pad to a child via the palette now clears the pad
focus and wipes the viewport, matching focusProcess's pad-exit path.

Adds a harness scenario (palette_over_scratchpad) that opens a pad,
opens the palette, types a query, and verifies that Esc leaves the
pad correctly repainted with no palette chrome lingering.

TODO.md

@@ -12,10 +12,6 @@
     still feels slow after ≥15 minutes — the structural drivers the
     audit named are all addressed, so a remaining symptom is a new
     one and probably wants fresh profiling.
-- [ ] Opening the command palette with a scratchpad open creates very buggy ui.
-  - Typing into the command palette doesn't work at all
-  - Hitting esc causes buggy chrome, the top border of the command palette is still visible
-  - This is only fixed by Ctrl + W, hitting esc again to close the palette, then re-opening it when over an agent view.
 - [ ] Context aware command palette options
   - Options for current scratchpad (delete, rename, edit) at the top when a scratchpad is selected.
   - Options for current agent (rename [renames tab], close) at the top when an agent is selected.