New Chat button clears current session instead of preserving it as a thread

[shogun444]

Describe the bug

Clicking "New Chat" button causes the current chat session to disappear entirely. The conversation is not saved as a previous thread and becomes inaccessible.

To Reproduce

1. Fresh scaffold: npx @openuidev/cli@latest create
2. Set up .env with Ollama local endpoint
3. Send a few messages in the chat
4. Click the "New Chat" button in the UI
5. The previous session disappears — no thread in sidebar, no way to get back

Expected behavior

Previous session should be saved as a thread in the sidebar, allowing users to switch between multiple conversations like a standard chat app.

Screenshots

Before clicking New Chat : Normal chat with AI-generated UI components visible on left

After clicking New Chat : Same session components on left panel disappeared after clicking New Chat

Desktop

• OS: Windows 11
• Browser: (tera browser)
• Version: (browser version)

Additional context

Confirmed on both fresh CLI scaffold and upgraded project. Likely related to default in-memory storage in ChatProvider not persisting threads on session switch.

[shogun444]

I did a bit of digging into the current implementation and found what seems to be causing the issue.

processMessage() creates the thread using createThread(), but the assistant messages generated afterwards are only stored in the local Zustand state and never persisted back to threadStorage.

Because of that, switchToNewThread() clears the local message state without the current conversation ever being saved.

It also looks like ThreadStorage doesn't currently provide a way to update an existing thread's messages.

I think a reasonable approach would be to:

-Add updateMessages(threadId, messages) to ThreadStorage.
-Implement it in the default in-memory storage.
-Persist messages after LLM streaming completes.
-Save the current thread before switching to a new one.

I'd be happy to put together a PR for this if this approach is good and nobody else is already working on it.

[abhithesys]

@shogun444
The approach looks good to me. only thing is I cannot think of any usecase other than in memory caching. How about instead of updateMessages we add an optional method called cacheMessages(threadId, messages). optional since not all storage would be implementing it.
If this looks good, feel free to create a PR.

[shogun444]

@abhithesys could you please review PR #710 ?