bug(cli): nested setState in useInputHistoryStore breaks StrictMode history

## What happened?

`packages/cli/src/ui/hooks/useInputHistoryStore.ts:94-106` calls `setPastSessionMessages` (and `recalculateHistory` → `setInputHistory`) inside another state updater:

```ts
setCurrentSessionMessages((prevCurrent) => {
const newCurrentSession = [...prevCurrent, trimmedInput];
setPastSessionMessages((prevPast) => {
recalculateHistory(newCurrentSession.slice().reverse(), prevPast);
return prevPast;
});
return newCurrentSession;
});
```

Updaters must be pure; StrictMode double-invokes them → double `recalculateHistory`, stale `prevPast`, lost/duplicated Up-arrow history.

## What did you expect to happen?

Compute outside updaters (refs for current/past + single `recalculateHistory` call) or a single `useReducer` action so history updates are atomic and idempotent.

## Client information

- Repo `google-gemini/gemini-cli` @ `main` `9c1b0a610`
- Area `packages/cli/src/ui/hooks/useInputHistoryStore.ts:89-109`
- Platform: interactive CLI, StrictMode dev

## Login information

N/A — UI hook; repro with StrictMode + rapid submits asserting Up-arrow order.

## Anything else we need to know?

Fix direction: `useReducer({current, past, history})` single action; add hook test for double-invoke safety and dedup order.

Read packages/cli/src/ui/hooks/useInputHistoryStore.ts:89-109 first, focusing on the nested state updaters and StrictMode behavior. Add the requested hook test for double-invoke safety and deduplication order; done means rapid submits preserve the expected Up-arrow history without duplicated or lost entries.

Written by the indexing model from the issue text.