feat(search-api-graphql)!: group result pagination into a shared Pagination type

[ddeboer]

Groups the search result envelope’s pagination fields into a single shared Pagination type. Every ‹Type›SearchResult now serves items / pagination / facets:

type Pagination {
  total: Int!
  page: Int!
  perPage: Int!
}

Why

• Fragment reuse: total/page/perPage were stamped into every per-type result type, so a client pager could not share one fragment across root types. With one shared type, fragment Pager on Pagination { total page perPage } serves them all.
• Extensibility: derived conveniences (totalPages, hasNextPage) get an obvious home later, instead of piling onto the result root next to items and facets.

The request arguments deliberately stay flat (page, perPage): GraphQL has no input fragments, so a pagination input object would add nesting without the reuse payoff. A Relay-style connection was considered and rejected – Typesense is natively offset-based, so cursors could only wrap offsets without cursor-stability guarantees, and a page-numbered faceted search UI wants totals and arbitrary page jumps (see ADR 3/4).

Changes

• build-schema.ts: build one shared Pagination object type; nest the applied pagination in the resolver result.
• Tests: queries and assertions updated; SDL stability snapshot regenerated; new assertion that Pagination is emitted once and referenced by every result type.
• Docs: result-envelope description in the search-api-graphql reference, sample queries in the build-a-search-api guide, and the ADR 4 SDL sketch (including the flat-arguments rationale).

Breaking change (minor bump under the zero-major scheme): clients selecting total, page or perPage at the result root must select pagination { total page perPage } instead. Known downstream: LOL’s search frontend and guide queries.