Add pagination support to list endpoints across all services

[haasonsaas]

Problem

None of the list endpoints across identity, memory, meter, prompts, or registry implement pagination. Parker hardcodes a batch size of 50. As data grows, these endpoints will become increasingly expensive and eventually timeout.

Affected endpoints include:

• GET /v1/prompts (prompts)
• GET /v1/memories (memory)
• Usage listing endpoints (meter)
• Session listing (identity)
• Agent listing (registry)

Proposal

1. Shared pagination types in proto or service-runtime

// proto/pagination/v1/pagination.proto
message PageRequest {
  int32 page_size = 1;    // max items per page, default 50, max 200
  string page_token = 2;  // opaque cursor for next page
}

message PageResponse {
  string next_page_token = 1;  // empty = last page
  int32 total_count = 2;       // optional, expensive for some queries
}

2. SQL helpers in service-runtime

// service-runtime/pagination/pagination.go
type PageRequest struct {
    PageSize  int
    PageToken string  // base64-encoded cursor
}

func (p PageRequest) SQLLimitOffset() (limit int, offset int)
func (p PageRequest) SQLCursor() (column string, value any) // for keyset pagination

3. Adopt in services

Start with prompts and memory (most likely to hit scale first), then roll out to others.

Design considerations

• Keyset pagination (cursor-based) is preferred over OFFSET for large datasets
• Page tokens should be opaque to clients (base64-encoded, not raw IDs)
• Default page size of 50, max 200, to prevent accidental full-table scans
• Include total_count only when explicitly requested (it requires a separate COUNT query)