feat(ui): add as-you-type filtering to the slash command menu

[aryansk]

Problem

The interactive slash menu (/ then arrow keys) lists 12 commands with no
way to filter. Users who remember part of a command (e.g. "ollama") have to
scroll and read every entry. Closes #61.

Change

Enables questionary's built-in as-you-type search filter in
_show_slash_menu (gcode/ui.py):

• Typing narrows the choices by case-insensitive substring match — "oll"
  filters to /ollama and anything else containing "oll".
• Backspace edits the filter; Enter runs the highlighted command; Esc still
  cancels (returns "").
• Arrow keys keep working; j/k navigation is disabled because questionary
  rejects combining it with the search filter (j/k are part of the prefix).
• If nothing matches the filter, questionary falls back to the full list,
  so the menu is never empty.

The instruction line now reads (↑↓ navigate, type to filter, Enter select, Esc cancel).

Why this approach

questionary (already a dependency, pinned >=2.1.1) ships this filter —
no new dependency, no custom key-binding code, and the interaction (typing,
backspace, Enter, Esc) is the library's own well-tested behavior.

Testing

uv run pytest:  111 passed (4 new UI tests: filter flag passed, cancel
                returns "", labels searchable by substring, every label
                maps back to its command)
uv run ruff check .:  All checks passed
uv run ruff format --check .:  32 files already formatted
uv run mypy gcode:  Success: no issues found in 12 source files
uv run bandit -q -r gcode/ -c pyproject.toml:  clean
uv run python -m compileall -q gcode demo:  clean

Acceptance criteria covered: "oll" filters to /ollama (substring match on
the command label), and arrow keys/Esc behavior is preserved (tested via
the mocked select call and cancel paths).

Documentation and release impact

• User-facing documentation updated
• Changelog/release note needed
• Migration or compatibility note needed
• No documentation impact

Review notes

• Known limitations: filtering is substring-based (questionary's built-in
  behavior), not fuzzy-scored; matches the issue's prefix example ("oll").
• Merge note: draft PR test: cover ui.py rendering helpers and slash menu #86 (test-only, test_ui.py coverage) may touch
  tests/test_ui.py; a trivial rebase may be needed if both merge — happy
  to do it.
• Follow-up issue: none.

[shauryagangrade]

Nice UX win — as-you-type filtering in the slash menu. Verified that questionary 2.1.1 (the pinned minimum) supports use_search_filter and use_jk_keys, so the config is valid; disabling j/k is correct since they conflict with the filter. The Esc/None/KeyboardInterrupt → "" contract preserves the prompt-loop behavior.

Notes (non-blocking):

• test_slash_menu_choice_labels_are_searchable is a weak assertion — it checks that some label contains "oll" rather than pinning the exact filtered set. Since the filter matches substrings of the full "{cmd} — {desc}" label, "oll" will also match any command whose description contains it, not just /ollama. Consider filtering on the command token only (e.g. precompute cmd.lower() choices) for predictable results.
• No test asserts the questionary call actually passes use_search_filter=True (the test_slash_menu_enables_type_to_filter test does — good, ignore this if it was intentional).
• Minor: use_search_filter=True may affect how the existing use_shortcuts=False behaves; the test asserts both, so this is covered.

Approve — ready once you mark the PR ready for review.

[github-actions]

Hi @aryansk, thanks for the PR! It references #61, which is reserved for first-time contributors. Since you've already contributed here, please work on a different, unreserved issue instead. Closing without merging. Thanks!