[Safety Critical] Input Handling Flaws deny 'Emergency Stop' on Touch Interfaces (Inequitable Keybindings)

### Context
Recent changes (e.g., PR #17993) to input handling have inadvertently introduced severe accessibility and safety issues for users on touch interfaces (Android/Termux/Tablets).

### 1. The "Inequitable" Double-Tap Requirement
The current "Double Ctrl+C to Quit" logic presumes a physical keyboard. On touch keyboards, `Ctrl` is often a toggle state, not a hold modifier.
* Performing a rapid "Double Ctrl+C" sequence is mechanically inconsistent across IMEs (e.g., `Ctrl(tap) -> c -> Ctrl(tap) -> c` vs `Ctrl(lock) -> c -> c`).
* **Result:** It is effectively impossible for mobile users to perform this "gesture" reliably. It forces them to abandon the standard signal key, leaving them with no clear, equitable way to exit or interrupt compared to physical keyboard users.

### 2. The "Runaway Agent" Hazard (No Brakes)
Due to input priority changes, both `ESC` and `Ctrl+C` signals are currently unreliable for interrupting active streams/tools:
* `ESC` is intercepted for "Rewind" navigation logic in `InputPrompt`.
* `Ctrl+C` is overloaded with "Quit" logic in `AppContainer`.
* **The Danger:** If an Agent misunderstands a prompt (Language Model Hallucination) and starts executing a destructive or looping chain of actions, the user **CANNOT STOP IT**. The CLI becomes a "driverless car without brakes."

### 3. Demand for a Deterministic Kill Switch
* We cannot rely on ambiguous shortcuts like "Double Tap" for safety-critical operations.
* **Requirement:** A single, deterministic, non-overloaded keystroke or UI mechanism that guarantees an immediate `AbortController.abort()` signal to the Agent loop, bypassing all UI state logic.
* If `Ctrl+C` is unreliable on touch, allow remapping to a single key (e.g., `F10`) or ensure `Ctrl+C` (Single Press) **ALWAYS** acts as an interrupt/abort signal, never a quit signal, unless explicit confirmation is given.