feat: give InputRedirect a command-line interface

[kerogenesis]

Why

Starting the tool from a shortcut, a scheduled task, or a script had no way to say what you wanted - the only path was the interactive menu, which needs a person at the keyboard. This gives InputRedirect a small command-line interface so the common cases can be named up front.

What

Redirect flags

• -m, --mouse - start as usual and switch the mouse redirect on
• -k, --keyboard - start as usual and switch the keyboard redirect on
• the two combine (order does not matter); with either present the menu is skipped and one green line (the same green the menu uses for an active switch) says what is running:
  • Mouse redirect active
  • Keyboard redirect active
  • Mouse and keyboard redirect active
• the thread then parks. There is deliberately no exit logic of its own: closing the window or pressing Ctrl+C is delivered to the console control handler exit::watch_for_close already installs, which switches the redirects back and ends the process - the exact same teardown the menu relies on.

Remove the driver

• -r, --remove-driver - confirms, removes the installed driver package, and offers the restart, then ends.
• if the package is not installed, it prints InputRedirect: no driver is installed, so there is nothing to remove. and exits without calling Driver::connect, so a removal request can never install the driver it was asked to remove.
• declining the confirmation prints Nothing was removed directly before the CLI session ends; it is not left waiting for a menu redraw that never happens.
• the menu key for this is now R (was D), so the key, the flag and the wording ("remove") all line up.

Help

• -h, --help - prints the usage and exits at once. No "press any key": help is something you typed, not a startup message a double-click user would otherwise miss.

Errors

• an unrecognised argument is refused with a new Error::Usage and exit code 5, rather than silently opening the menu, so a misspelt flag cannot look like it did nothing.
• the error points to InputRedirect --help, keeping the guidance complete as options are added.

When more than one thing is asked for, the request that undoes the most wins, so nothing is half-done and then thrown away: --help first, then --remove-driver, then the redirects. With no arguments the behaviour is unchanged: the interactive menu opens as before.

Files

• src/app/cli.rs (new) - parses the arguments into a Request (Menu, Redirect(Requested), RemoveDriver, Help) and produces the one status line the flag mode prints.
• src/app/mod.rs - run parses the command line first; --help answers before anything is claimed, --remove-driver checks for an installed package before startup and reports both no-op outcomes directly, and a redirect hands off to run_headless.
• src/main.rs - usage errors point to --help rather than carrying a partial hard-coded flag list.
• src/ui/prompt.rs - the remove-driver menu key moves from d to r.
• src/ui/screen.rs - the menu row shows R.
• README.md - new Command line section with the usage/options block, and the Quick Start key table now shows R.

Tests

src/app/cli.rs unit tests cover: no arguments (menu), each flag alone (long and short), both redirects together, order independence, a repeated flag, --help and --remove-driver each winning over a redirect alongside them, --help winning over --remove-driver, an unknown argument (alone and after a valid one), and each redirect combination mapping to the right status line. src/ui/prompt.rs tests are updated for the R scan code.

Verification

The Windows CI runs cargo fmt --all --check, cargo clippy --locked --all-targets -- -D warnings, cargo test --locked --all-targets, and cargo build --locked --release; the dependency audit runs separately. No dependencies were added, so Cargo.lock is unchanged.