[rekram1-node]

Why

Paging for session.list (cursor parsing, the default limit of 50, and building the previous/next cursors) lived in the server handler, so only HTTP clients could use it. Moving it into Core's Session.list lets the plugin host offer the same paging by calling the same method. HTTP behavior is unchanged.

Change

• Session.list in Core now pages, with the same name, inputs, and output as HTTP session.list. It takes the list filters plus optional limit and cursor, defaults to 50, and returns { data, cursor: { previous, next } }. A cursor carries the filters of the request that produced it, as before.
• Add Session.InvalidListCursorError for an unreadable cursor.
• The session.list handler calls Session.list and maps that error to the existing InvalidCursorError with the same "Invalid cursor" message.
• Session.remove reads children from SessionStore.list, so it still removes every child rather than the first page. It was the only other caller of Session.list in Core source.

Validation

• packages/core/test/session-list.test.ts: filtered paging in both directions matches the store's unpaged results, the default limit is 50, and invalid cursors fail
• Core test files that call Session.list or remove sessions (71 pass); bun test in packages/server
• bun typecheck in packages/core and packages/server