[Test🧪] Cover the dangerous-command confirmation flow

Start with the existing mod tests in rocketmq-tools/rocketmq-admin/rocketmq-admin-tui/src/rocketmq_tui_app.rs and its handle_key_event setup, then inspect handle_confirmation_key, apply_action, and prepare_execution. Add the listed confirmation-flow cases there, and test confirmation_prompt in src/state.rs. Done means every acceptance case is asserted, no production code changes are made, and cargo fmt -p rocketmq-admin-tui -- --check plus cargo test -p rocketmq-admin-tui pass.

Prerequisites

• I have searched existing test issues

Test Scope

Crate: rocketmq-admin-tui
Files: rocketmq-tools/rocketmq-admin/rocketmq-admin-tui/src/rocketmq_tui_app.rs
       handle_confirmation_key at line 316, the Confirmation arm of apply_action at line 522,
       prepare_execution at line 643
       rocketmq-tools/rocketmq-admin/rocketmq-admin-tui/src/state.rs
       confirmation_prompt at line 566
Coverage: no test ever enters CommandExecutionState::Confirming

The TUI refuses to run a command whose risk level requires confirmation until the
operator types an expected string back. That gate is the last thing standing
between a mistyped shortcut and a destructive admin call, and no test exercises
it.

// src/rocketmq_tui_app.rs lines 331-343
            KeyCode::Enter => {
                if let CommandExecutionState::Confirming {
                    execution_id,
                    command_id,
                    expected,
                } = self.state.execution.clone()
                {
                    if self.state.confirm_input.trim() == expected {
                        self.start_execution(execution_id, command_id);
                    } else {
                        self.state.last_error = Some(format!("confirmation must match '{expected}'"));
                    }
                }
            }

The whole path is untested: entering Confirming when a dangerous command is
executed, the exact-match rule including the trim, rejecting a mismatch, Esc
cancelling, and Backspace editing the typed text. Nothing in the repository's
tests mentions Action::ConfirmRequested, Action::HelpToggled,
Action::ResultCleared, Action::ArgChanged, Action::FocusNext, or
Action::FocusPrevious either.

The test harness already exists. src/rocketmq_tui_app.rs has a mod tests block
at line 831 that builds an app with RocketmqTuiApp::new(test_client_runtime())
and drives it through handle_key_event, so the new cases belong beside the
existing ones and need no new scaffolding.

Test Cases

Add cases to the existing mod tests in src/rocketmq_tui_app.rs. Follow the
style of the tests already there for constructing the app and sending keys.

Entering confirmation:

• Selecting a command whose risk level is Dangerous and sending Ctrl+R
  leaves state.execution in CommandExecutionState::Confirming, and the
  captured expected string is the one the command declares.
• A command that does not require confirmation executes directly, so the new
  test proves the gate is specific rather than blanket.

Matching:

• Typing the exact expected string and pressing Enter starts the
  execution, proving confirm_input reaches the execution state.
• Typing the expected string with surrounding whitespace and pressing Enter
  also starts it, pinning the .trim() in the comparison.
• Typing a wrong string and pressing Enter does not start execution,
  leaves the state in Confirming, and sets last_error to a message
  containing the expected value.
• After a mismatch, typing the correct string and pressing Enter still
  works, proving the mismatch did not move the state machine.

Editing and cancelling:

• Backspace removes the last character of confirm_input, including on an
  already-empty input where it must not panic.
• Esc emits Action::CancelExecution and leaves Confirming.
• A character key appends to confirm_input rather than reaching the global
  shortcut table.

confirmation_prompt in src/state.rs:

• A Dangerous command produces wording that includes the word dangerous,
  and a lower-risk mutating command does not.
• A command with no confirmation requirement returns None.

Willing to contribute?

• I can submit a PR for this

Acceptance Criteria

• Every case above is covered by an assertion in
  src/rocketmq_tui_app.rs or, for confirmation_prompt, in src/state.rs.
• No production code change. These tests pin the current gate.
• cargo test -p rocketmq-admin-tui passes.

Validation

Run from the repository root:

cargo fmt -p rocketmq-admin-tui -- --check
cargo test -p rocketmq-admin-tui