[backend] P1 perf: /api/history fetches full transcript then slices in memory — no gateway pagination, frontend hardcodes limit=1000

[Interstellar-code]

Problem

The history pipeline is "fetch everything, trim on the consumer" at every layer:

1. src/routes/api/history.ts:95 — getMessages(sessionKey) pulls the ENTIRE message list from the gateway; :119 applies messages.slice(-limit) in memory. limit is cosmetic — the full transcript (tool payloads + thinking blocks) always crosses the wire gateway → workspace.
2. src/server/hermes-api.ts:264-275 and claude-dashboard-api.ts:133-138 — message endpoints accept no limit/offset.
3. src/screens/chat/chat-queries.ts:69 — frontend hardcodes limit: '1000', making the trim a no-op for most sessions.
4. use-realtime-chat-history.ts:492 — full re-fetch every 30s plus on every stream-clear.
5. use-chat-history.ts:394-397 — staleTime: 0 + refetchOnWindowFocus: true with no streaming guard: re-focusing the tab mid-stream refires a full history fetch that races/overwrites the live SSE buffer. Likely contributor to when I have given the task on the chat and leave the chat session the response is getting some what scrappy.., I have to stay in the chat window to ge... #208 (responses "scrappy" when leaving and returning to the chat window).
6. history.ts:57-92 — resolving "main" costs listSessions(30,0) + getMessages = two sequential gateway round-trips per default view; the main-resolution heuristic is duplicated in send-stream.ts.

Symptom: slow session open and heavy 30s background sync on large sessions (e.g. the 505-message session); SSR CPU/memory per refetch.

Fix

• Push limit/offset (or ?since=<id> delta) into the gateway messages call so trimming happens at source — needs a small hermes-agent change; workspace-side mitigation until then: request tail only, disable focus-refetch while streaming.
• Extract the "main" resolution into one shared helper; briefly cache the resolved id.

Found in chat-area audit 2026-06-11. Related: #208.