fix(tui): recall accepted slash commands locally

[fcoury-oai]

TL;DR

• Adds recognized slash commands to the TUI's local in-session recall history.
• This is the MVP of the whole feature: it keeps slash-command recall local only: nothing is written to persistent history, app-server history, or core history storage.
• Treats slash commands like submitted text once they parse as a known built-in command, regardless of whether command dispatch later succeeds.

Problem

Slash commands are handled outside the normal message submission path, so they could clear the composer without becoming part of the local Up-arrow recall list. That made command-heavy workflows awkward: after running /diff, /rename Better title, /plan investigate this, or even a valid command that reports a usage error, users had to retype the command instead of recalling and editing it like a normal prompt.

The goal of this PR is to make slash commands feel like submitted input inside the current TUI session while keeping the change deliberately local. This is not persistent history yet; it only affects the composer's in-memory recall behavior.

Mental model

The composer owns draft state and local recall. When slash input parses as a recognized built-in command, the composer stages the submitted command text before returning InputResult::Command or InputResult::CommandWithArgs. ChatWidget then dispatches the command and records the staged entry once dispatch returns to the input-result path.

Command-name recognition is the only validation before local recall. A valid slash command is recallable whether it succeeds, fails with a usage error, no-ops, is unavailable while a task is running, or is skipped by command-specific logic. An unrecognized slash command is different: it is restored as a draft, surfaces the existing unrecognized-command message, and is not added to recall.

Bare commands recalled from typed text use the trimmed submitted draft. Commands selected from the popup record the canonical command text, such as /diff, rather than the partial filter text the user typed. Inline commands with arguments keep the original command invocation available locally even when their arguments are later prepared through the normal submission pipeline.

Non-goals

Persisting slash commands across sessions is intentionally out of scope. This change does not modify app-server history, core history storage, protocol events, or message submission semantics.

This does not change command availability, command side effects, popup filtering, command parsing, or the semantics of unsupported commands. It only changes whether recognized slash-command invocations are available through local Up-arrow recall after the user submits them.

Tradeoffs

The main tradeoff is that recall is based on command recognition, not command outcome. This intentionally favors a simpler user model: if the TUI accepted the input as a slash command, the user can recall and edit that input just like plain text. That means valid-but-unsuccessful invocations such as usage errors are recallable, which is useful when the next action is usually to edit and retry.

The previous accept/reject design required command dispatch to report a boolean outcome, which made the dispatcher API noisier and forced every branch to decide history behavior. This version keeps the dispatch APIs as side-effect-only methods and localizes history recording to the slash-command input path.

Inline command handling still avoids double-recording by preparing inline arguments without using the normal message-submission history path. The staged slash-command entry remains the single local recall record for the command invocation.

Architecture

ChatComposer stages a pending HistoryEntry when recognized slash-command input is promoted into an input result. The pending entry mirrors the existing local history payload shape so recall can restore text elements, local images, remote images, mention bindings, and pending paste state when those are present.

BottomPane exposes a narrow method for recording that staged command entry because it owns the composer. ChatWidget records the staged entry after dispatching a recognized command from the input-result match. Valid commands rejected before they reach ChatWidget, such as commands unavailable while a task is running, are staged and recorded in the composer path that detects the rejection.

Slash-command dispatch itself now lives in chatwidget/slash_dispatch.rs so the behavior is reviewable without adding more weight to chatwidget.rs. The extraction is behavior-preserving: the dispatch match arms stay intact, while the input flow in chatwidget.rs remains the single place that connects submitted slash-command input to dispatch.

Observability

There is no new logging because this is a local UI recall behavior and the result is directly visible through Up-arrow recall. The practical debug path is to trace Enter through ChatComposer::try_dispatch_bare_slash_command, ChatComposer::try_dispatch_slash_command_with_args, or popup Enter/Tab handling, then confirm the recognized command is staged before dispatch and recorded exactly once afterward.

If a valid command unexpectedly does not appear in recall, check whether the input path staged slash history before clearing the composer and whether it used the ChatWidget slash-dispatch wrapper. If an unrecognized command unexpectedly appears in recall, check the parser branch that should restore the draft instead of staging history.

Tests

Composer-level tests cover staging and recording for a bare typed slash command, a popup-selected command, and an inline command with arguments.

Chat-widget tests cover valid commands being recallable after normal dispatch, inline dispatch, usage errors, task-running unavailability, no-op stub dispatch, and command-specific skip behavior such as /init when an instructions file already exists. They also cover the negative case: unrecognized slash commands are not added to local recall.

[canvrno-oai]

Reviewed, tested and working.

I do wonder if we may want to add a whitelist for slash commands that are eligible for recall, as some may be less relevant under daily recall use cases.