pagination: help consumers test and version the page token format

The "page_token" format that we use for pagination is implicitly part of the consumer's API surface. It doesn't appear in the OpenAPI spec, and clients aren't supposed to know or care about the format, but critically: if the consumer changes the structure of their PageSelector type, that can invalidate URLs generated before the change. This has impact on consumers that might want to do a rolling upgrade of a fleet of servers without breaking clients in confusing ways.

I'm not sure how best to handle this. One way would be to provide a test function for consumers to generate an OpenAPI-like spec for the page selector. Then they could deal with this the same way they might deal with the actual OpenAPI spec, probably by generating it from the source, storing it in version control, and raising a flag whenever it changes.

Start by locating the pagination implementation and the PageSelector type, then review how page_token values are produced and represented relative to the OpenAPI specification. Define the consumer-facing compatibility requirement and identify what generated or stored specification would reveal an incompatible change. Done should include an agreed approach for detecting page-token format changes.