Thread names can get out of sync: localStorage override vs Codex thread name (single source of truth)

Start with src/features/threads/hooks/useThreadTurnEvents.ts and src/features/threads/hooks/useThreadActions.ts, tracing localStorage reads and thread/name/updated handling. Verify the rename action still calls thread/name/set with an optimistic update, and confirm that external Codex name updates are reflected in the thread list without a local override masking them.

CodexMonitor persists renamed thread names in localStorage (codexmonitor.threadCustomNames) in addition to setting the name in Codex via thread/name/set.

If a local custom name exists, CodexMonitor ignores thread/name/updated events (src/features/threads/hooks/useThreadTurnEvents.ts early-return), so renames done outside CodexMonitor (Codex CLI / VSCode / another machine syncing CODEX_HOME) do not show up and the UI can diverge.

Repro

1. Rename a thread in CodexMonitor.
2. Rename the same thread in Codex (outside CodexMonitor) to a different name.
3. CodexMonitor keeps showing the old name because the local override wins (also used when building the thread list in src/features/threads/hooks/useThreadActions.ts).

Expected
Codex thread name is the single source of truth; CodexMonitor always reflects Codex names / thread/name/updated.

Actual
Local custom name can permanently mask Codex updates.

Suggestion

• Remove threadCustomNames persistence and rely only on Codex names (keep rename by calling thread/name/set, with optimistic UI update).
• Optional migration: on startup, push any existing local overrides into Codex once, then clear localStorage.