main-v2 absorbed a large batch of merges today and this branch now conflicts. Could you rebase onto the latest main-v2? The change itself is still wanted — once it's green I'll review promptly (fork CI gets approved as soon as you push).

Specifics for the rebase round so it's one pass:

1. navigatingHistoryRef rests on a React misconception — programmatic setText never fires onChange (only user input does), so the ref is consumed by the user's first real keystroke instead of by navigation. Net effect: historyIndex survives an edit, and the next ArrowUp throws the user's edit away. Delete the ref entirely: any onChange is user input → reset history mode.
2. cursorOnFirstLine only checks \n — on a soft-wrapped long line ArrowUp recalls history instead of moving the caret up a visual line. Safest cheap rule: only trigger when the caret is at position 0 or the textarea has a single visual line.
3. Cap the history (e.g. 50 entries) — it currently grows unbounded in localStorage.
4. Validate the localStorage parse (Array.isArray + string elements) per the boundary-validation rule; a corrupted entry currently throws into the component.
5. Strip the restating comments (// Save to input history, etc.) per the repo comment policy.

Also note #3722 touches Composer.tsx and will land first — rebase over it.

Closing this as superseded by #4349.

Thanks @PsjJourney for the earlier implementation. I carried the contribution forward in #4349 by crediting:

• establishing Up/Down as the desktop composer prompt-history navigation gesture
• exploring draft preservation/restoration while moving through recalled prompts
• keeping the behavior scoped to composer keyboard handling

#4349 keeps that UX direction and implements it with persisted session-backed replay plus broader regression coverage. @PsjJourney is also listed as a co-author on the updated #4349 commit.