Align Desktop Hub session models with session_id responses

[DeliciousBuding]

Problem

Desktop's Hub REST client models sessions as id, but the Hub server serializes session identifiers as session_id for both create and list responses. This means a server-shaped response cannot satisfy the Desktop Session contract without an explicit mapper, and any caller that reads session.id receives undefined.

Evidence

• hub-server/internal/service/session.go defines CreateSessionResponse.SessionID with json:"session_id" and returns that from CreatePrivateSession / CreateGroupSession.
• The same file defines SessionListItem.SessionID with json:"session_id" and fills it in ListSessions and SearchSessions.
• app/desktop/src/api/hubClient.ts defines export interface Session { id: string; ... }, and listSessions, searchSessions, createPrivateSession, and createGroupSession all return Session or Session[] directly with no response mapper.
• app/desktop/src/__tests__/hubClient.test.ts mocks { id: 's1' } and { id: 's_new' }, so the tests validate the Desktop-only shape instead of the Hub wire shape.
• api/openapi.yaml does not give these client session endpoints a concrete response schema that would catch the mismatch.

Impact

Session IDs are the key used by message, member, and session-management endpoints. Once Desktop starts consuming real Hub session responses, code that expects session.id will pass undefined or a locally invented ID into later calls.

Suggested fix

Pick one contract and make it explicit:

1. Either keep Desktop's internal Session.id and add a Hub response mapper from session_id to id, with tests using server-shaped fixtures.
2. Or change Desktop's session type and callers to use session_id consistently.

Also add concrete OpenAPI schemas for the list/search/create session responses so future generated clients or tests catch this class of mismatch.

Acceptance criteria

• hubClient tests include server-shaped { session_id: ... } fixtures for list, search, private create, and group create.
• Callers can reliably obtain the real Hub session ID from these responses.
• OpenAPI documents the exact response fields for the session endpoints.