fix(agent/new): use randomUUID for new-session lock key to prevent session collision

[Cyriellewu]

Summary

POST /api/agent/new derived its de-duplication lock key from Date.now() alone, which has only millisecond resolution. startRpcSession() (lib/rpc-manager.ts) coalesces concurrent callers by that key via an in-flight lock, so two new-session requests arriving in the same millisecond received the same AgentSessionWrapper and the same sessionId — silently merging two independent chats into one pi session.

Fixes #227

Root cause

app/api/agent/new/route.ts:

const tempKey = `__new__`;

Session creation takes tens to hundreds of ms, so the in-flight lock stays live well beyond 1 ms. Any second POST /api/agent/new computing the same tempKey gets the first request's in-flight promise, and therefore the same real session — a cross-conversation isolation failure the client cannot detect or recover from.

Fix

Use randomUUID() for the key (already imported and used the same way throughout lib/rpc-manager.ts):

const tempKey = `__new__`;

A distinct key per request means the in-flight lock only ever coalesces retries of the same logical request, never two different ones. __new__/tempKey has exactly one call site in the repo, and nothing depends on the key being time-ordered or parseable, so there is no downstream impact.

Testing

The repo has no test harness, so this was verified by inspection and the deterministic reproduction from the issue (two near-simultaneous POST /api/agent/new now return distinct sessionIds). The change is a drop-in of an existing, already-used pattern.