Ctrl+E shortcut conflicts with standard readline "end of line" behavior

[yidinghan]

 ### Describe the bug

 `Ctrl+E` is a standard readline/Emacs shortcut for moving the cursor to the end of the line. However, Copilot CLI remaps it to "expand tool input/output", which breaks the expected behavior.

 This makes it inconvenient to edit longer prompts in the input box.

 ### Affected version

 0.0.387

 ### Expected behavior

 `Ctrl+E` should move the cursor to the end of the line (standard readline behavior), or at least provide an alternative shortcut for this function.

 ### Proposed solution

 - Use a different shortcut for "expand tool output" (e.g., `Ctrl+O` which is already used for expand timeline)
 - Or allow `Ctrl+E` to retain its readline behavior in the input box

[igorclark]

Just a +1 because this is a major flow-kill - ctrl-e is embedded in muscle memory but accidentally running 'expand tool input/output' in a long session is disastrous, as it makes Copilot scroll and scroll and scroll text to the point where you often have to just kill the session, start over and hope you didn't lose everything. The docs say that ctrl-E is now 'end of line' but ctrl-e is 'expand all items in response timeline', which is pretty crazy - it should be the other way around, i.e. you have to make an effort to hit shift-ctrl-E in order to get the non-standard readline behaviour. This and all the others in #1069 are really crucial for a CLI app not to break. Thanks 🙏

[examon]

This was taken care of in v0.0.396. Ctrl+E now moves the cursor to the end of the line while typing — the timeline expansion only triggers when the input field is empty. If you're still seeing the conflict, feel free to reopen this issue.