Followup #3500052: Introduce pagination for HTTP API to get list of content(pages).

✨ Provide an API for listing available pages Active is in.

Note: also see the caveat at #3500052-24: Provide HTTP API for listing Page content entities that can be updated by the current user → . If that ever changes, we would not need to do this.

What is this postponed on?

Why not use JSON:API instead of re-implementing half of it?

#6 Good Q! Quoting docs/config-management.md:

XB intentionally does not use Drupal core's [JSON:API module](https://jsonapi.org/), because:
-  requiring the Drupal JSON:API module to be installed is excessive
-  XB's HTTP API does not need pagination support
-  XB tracks all available Components as config entities, but those actually do not need to be exposed in full; there's
   no need to modify them from the  client-side UI, and there already is `Component::normalizeForClientSide()` which
   enriches it with additional metadata, matching the UI's needs
- XB's HTTP API does not need to surface relationships between XB's config entities — that mostly makes sense for
  _content entity_ relationships (i.e. "entity references")

However, that's specifically about config entities. This issue is about pagination for one single place. And I'm actually not sure we need it at all 😅

I think it makes much more sense to never allow access to paginate through all content entities of some type — instead, you'd really want to search for something particular! And that's exactly what ✨ Allow searching for content in the editor navigation Active is doing.

So, being bold, and closing this.