fix: prevent ClassCastException in RestAI chat when making consecutive requests

[octo-patch]

Fixes #1796
Fixes #1812

Problem

When using a custom REST AI provider (chatWithRestAi), making two consecutive
requests to /api/ai/chat causes a ClassCastException and a 500 error on the
second request. Refreshing the page (which generates a new uid) restores
functionality temporarily.

Root cause: chatWithRestAi stores the message history as a JSON string via
JSONUtil.toJsonStr(messages), but getFastChatMessage() later retrieves that
value and casts it directly to List<FastChatMessage>. The cast succeeds on the
first call (cache miss → empty list created), but fails with ClassCastException
on every subsequent call when the cached JSON string is retrieved.

Stack trace from #1796:

java.lang.ClassCastException: class java.lang.String cannot be cast to class java.util.List
    at ai.chat2db.server.web.api.controller.ai.ChatController.getFastChatMessage(ChatController.java:465)
    at ai.chat2db.server.web.api.controller.ai.ChatController.chatWithRestAi(ChatController.java:266)

Solution

1. Store the List<FastChatMessage> object directly in the cache (removing the
   JSONUtil.toJsonStr() call), consistent with all other AI provider methods.
2. Add a defensive instanceof List check in getFastChatMessage to avoid
   unchecked casts and handle any stale cache entries gracefully.

Testing

• Verified the cache write and read types are now consistent for the RestAI path.
• The instanceof guard ensures stale entries (from previous deployments) fall
  back to a fresh empty list instead of crashing.