High priority: bare left/right arrow hijacks cursor key for session navigation, discarding in-progress input (data loss)

## Summary (high priority — causes data loss)

In the interactive CLI, the **bare left/right arrow keys are overloaded for session navigation**. Specifically:

- **Left arrow** opens the Sessions sidebar.
- A **second left arrow within ~70–450 ms** starts a **new session** (a double-tap gesture; the timing window is hardcoded).
- **Right arrow** jumps to the Agents tab.

This overloads the single most fundamental cursor key in any text field, and — most importantly — **it silently discards in-progress input** (a correction/follow-up I was composing), with no confirmation and no auto-stash.

## Core principle: bare arrow keys should not be app keybindings in a CLI

Binding **bare (unmodified) arrow keys to application actions is a fundamental anti-pattern for a terminal/CLI program.** In a text interface the arrow keys have exactly one universally understood job — move the cursor. Users rely on that contract from every shell, REPL, and terminal editor. Any application-level navigation (sidebars, tabs, session switching, new session) should be bound to a modifier or leader chord (e.g. `ctrl+…`, or the existing `ctrl+x → …` pattern), never to a naked arrow key. Overloading bare arrows — especially with a destructive action — guarantees accidental, muscle-memory-driven mistakes.

## Why this is high priority

- **Data loss:** while composing a correction or follow-up (often while the agent is working), reaching for the arrow key out of habit triggers navigation / a new session and **destroys the correction I was in the middle of writing**. Silent loss of user input to a stray cursor keypress is a serious defect, not a cosmetic one.
- **Violates universal expectations:** left/right arrows mean "move the cursor" in every shell, editor, and text field. Overloading them — especially with a *destructive* double-tap gesture — breaks muscle memory everyone has.
- **No escape hatch:** there is no setting to disable or rebind this in `/settings` or `settings.json`, and the binding is not listed in the public keyboard-shortcut help. It's effectively hidden and unavoidable.

## Steps to reproduce

1. Start `copilot` (interactive).
2. Press **Left** (for example while composing or correcting a prompt, or while the agent is working).
- The Sessions sidebar opens.
3. Press **Left** again quickly (within ~70–450 ms).
- A **new session** is started and any in-progress prompt/correction is discarded.

> Note: the exact conditions under which a bare arrow is captured for navigation vs. cursor movement are not documented; the observed effect is that a correction in progress can be lost.

## Expected behavior

- Bare left/right arrows should only move the cursor. They should never trigger navigation or start a new session.
- In-progress input must never be discarded without confirmation or an automatic stash.

## Suggested fixes (any one resolves it)

1. Don't bind bare left/right to navigation — require a modifier or leader chord (e.g. `ctrl+x → …`, consistent with the existing `ctrl+x → h` to hide the sidebar).
2. Add a setting to disable arrow-key session navigation.
3. Never discard in-progress input without confirmation or auto-stash.
4. At minimum, remove the destructive double-tap-left → new-session binding.

## Environment

- Copilot CLI: **1.0.71-3**
- OS: **Windows**

Start by reproducing the behavior in the interactive CLI on Windows, using the listed left-arrow and double-tap steps while composing input. Review the keyboard shortcuts and settings areas referenced in `/settings` and `settings.json`; done means bare arrows move the cursor and no in-progress input is discarded during navigation.

Written by the indexing model from the issue text.