[Bug] Chat \"Read-only\" and \"New Chat\" button failure in non-secure (HTTP) contexts

[Erudition]

Description:
When accessing the GoClaw dashboard over plain HTTP (e.g., via an IP address like http://10.7.1.25), the chat interface becomes permanently "Read-only," and the "New Chat" button fails to function correctly. This is primarily due to modern browser security policies and restrictive frontend logic.

1. crypto.randomUUID() Unavailable in HTTP

Problem: The crypto.randomUUID() API, used for generating new session IDs in the frontend, is disabled by browsers in non-secure (non-localhost, non-HTTPS) contexts.
Context: When a user clicks "New Chat," the ID generation fails silently or returns undefined, resulting in malformed session keys like agent:AGENTID:ws:direct:undefined.

2. Restrictive isOwnSession Logic

Problem: The frontend's ownership check (isOwnSession) was too narrow, failing to recognize valid sessions generated with non-default scoping or newer key formats.
Context: Sessions with the main scope or those that didn't strictly match the ws:direct: prefix were being flagged as "belonging to another user," even though the backend correctly filters these by the authenticated user ID.

---

Steps Taken / Patches Applied:

1. Implemented uniqueId() Fallback:
Updated use-chat-sessions.ts and chat-page.tsx to use a robust fallback for session ID generation when crypto.randomUUID() is unavailable.

// Fix: Use uniqueId fallback
const convId = typeof crypto.randomUUID === 'function' ? crypto.randomUUID() : uniqueId();

2. Expanded isOwnSession Inclusivity:
Updated ui/web/src/lib/session-key.ts to recognize all WebSocket-based sessions and the global main session as "own" sessions.

export function isOwnSession(sessionKey: string, userId: string): boolean {
  if (!userId) return false;
  const { scope } = parseSessionKey(sessionKey);

  // Any WS session seen by the web UI is ours (filtered by backend)
  if (scope.startsWith(\"ws:direct:\") || scope.startsWith(\"ws:\") || scope === \"main\") {
    return true;
  }
  // ...
}

---

Expected Behavior:

• The "New Chat" button should always generate a valid, unique session ID.
• The chat input should be available for any session returned by the backend for the current user, regardless of whether the scope is main or ws:direct:.

Environment:

• Host OS: Linux
• Deployment: Docker / Portainer
• Access Method: Plain HTTP via IP address

[vanducng]

Both issues I believed already fixed on main:

1. crypto.randomUUID() — fallback added in 59a52f1e
2. isOwnSession — reworked in 8409db58. main scope sessions are channel-originated (Telegram, etc.) — read-only in web UI by design.

Let us know if it persists after pulling the latest version.