Make the command palette a bindable action, shown in the footer

[tconbeer]

Closes #223

What are the key elements of this solution?

• The command palette is now a Harlequin action, command_palette, in HARLEQUIN_ACTIONS, with the description "Commands", show=True, and priority, so it works while the Query Editor has focus. It can be rebound in a keymap like any other action.
• The VS Code keymap binds it to ctrl+p, right after help. Footer keys follow binding order, so the footer reads ^q Quit f1 Help ^p Commands f8 History ….
• Harlequin sets ENABLE_COMMAND_PALETTE = False, so Textual doesn't add its own ctrl+p binding, and sets use_command_palette = True, which keeps the palette on. Without that, a keymap that moved the palette to another key would leave ctrl+p opening it too.
• The help screen's tip names whichever key opens the palette, instead of a hardcoded ctrl+p.
• The main app's Footer keeps show_command_palette=False. The key is an ordinary footer key, so no CSS is needed and it covers nothing.

Why did you design your solution this way? Did you assess any alternatives? Are there tradeoffs?

• The first version of this PR used Textual's docked palette key, on the right of the footer. It covered real keys: f3 Find Next at 120 columns, and ^s Save Query at 80. An ordinary key covers nothing.
• That version also declared the binding in Harlequin.BINDINGS. A class-level binding on ctrl+p shares its list across instances, because Textual's BindingsMap.copy() is shallow, so user ctrl+p bindings leaked between app instances in one process. Binding it through the keymap, like every other action, avoids that.
• Textual's own settings (ENABLE_COMMAND_PALETTE and use_command_palette) turn off its built-in binding, so nothing reaches into _bindings.
• Tradeoff: a user whose keymaps don't build on vscode and don't bind command_palette gets no palette key. That's consistent with every other action.

Does this PR require a change to Harlequin's docs?

• No.
• Yes, and I have opened a PR at tconbeer/harlequin-web.
• Yes; I haven't opened a PR, but the gist of the change is: the footer shows ^p Commands, and the palette is bindable as command_palette (default ctrl+p in the VS Code keymap). Screenshots of the main screen in the docs will be missing the new footer key.

Did you add or update tests for this change?

• Yes.

• No, I believe tests aren't necessary.

• No, I need help with testing this change.

• test_footer_shows_palette_key: the footer lists Quit, Help, Commands first, and ctrl+p opens the palette.

• test_palette_key_is_configurable: a keymap that binds command_palette to f11 shows f11 Commands. f11 opens the palette and ctrl+p doesn't.

  • Removing either ENABLE_COMMAND_PALETTE = False or use_command_palette = True fails both this test and the footer test.

• test_help_screen_keys_panel_tip_without_a_binding: the tip names the palette's key, or none.

• Snapshots: 145 changed, 141 regenerated on Python 3.10 and 4 py12-only ones on 3.12. I compared every changed SVG to the base by script:

  • 135 differ only in the footer row (^p Commands after Help).
  • The other 10 are the keys app, which gains a "Command Palette" row, and the Keys panel, which lists the new binding. Both shift the rows below.

Please complete the following checklist:

• I have added an entry to CHANGELOG.md, under the [Unreleased] section heading. That entry references the issue closed by this PR.
• I acknowledge Harlequin's MIT license. I do not own my contribution.

🤖 Generated with Claude Code

https://claude.ai/code/session_015eYrDYJPPnVY7KeHm1oTBY