fix(api): add pagination to GET /api/sessions/{id}/messages

[mahdiwafy]

Summary

Adds optional limit and offset query parameters to the session messages endpoint. Previously returned ALL messages in a single response — sessions with 500+ messages produced 1.2–1.6 MB JSON payloads causing GIL starvation and WebSocket timeouts on Desktop (#60155).

Changes

• hermes_state.py: SessionDB.get_messages() accepts optional limit and offset params. Uses SQL LIMIT ? OFFSET ? when provided. No-op when omitted (backward compatible).
• hermes_cli/web_server.py: GET /api/sessions/{id}/messages accepts limit and offset query params. Limit clamped to 500 max. Response includes pagination: {limit, offset, returned}.

Backward Compatibility

Callers that omit limit get the old behavior (all messages). No breaking change to existing API consumers.

Example

GET /api/sessions/20260707_102815_c4d80b/messages?limit=50&offset=0
→ {"session_id": "...", "messages": [...50 items...], "pagination": {"limit": 50, "offset": 0, "returned": 50}}

Closes #60155

[alt-glitch]

This was generated by AI during triage.

Related: #60155 (the bug this closes), #38370 (the pagination feature request), and #38942 (an open competing PR that adds limit/offset to this same endpoint plus /api/jobs). This is a competing/overlapping implementation of the same session-messages pagination — flagging the cluster so a maintainer can pick between this and #38942.

[mahdiwafy]

Superseded by #60883 which includes this pagination work plus additional improvements (compact_rows SQL projection, system_prompt stripping, offset-without-limit fix). Authorship preserved via cherry-pick. Closing in favor of the salvage PR.

[kshitijk4poor]

Merged via #60883 (rebase) — your pagination commit landed on main as 0d5549a with your authorship preserved. One follow-up on top: offset-without-limit was silently ignored (SQLite requires LIMIT for OFFSET), now emitted as LIMIT -1, plus regression tests for paging order and the soft-deleted-row interaction. Thanks!