[FEATURE] Add robot coverage for REST page_number pagination and pluggable GraphQL pagination strategies #684

Summary

The three features from the any-sdk GraphQL/pagination uplift are implemented and wired through stackql, but part of the planned robot coverage was never added. This issue tracks the remaining test work only; no feature code is expected to change.

What already shipped:

• GraphQL response.transform consumption: wired in internal/stackql/primitivebuilder/graphql_single_select_acquire.go via PR graphql enhancements #658 (d1f204e), covered by any-sdk unit tests and the live Trevorblades Continents GraphQL Response Transform robot test in test/robot/integration-traffic-lights/.
• Pluggable GraphQL cursor strategies (cursor_after, keyset, offset, page_info): plumbed through the same dispatch site; strategies are unit tested in any-sdk (pkg/graphql/graphql_test.go).
• REST algorithm: page_number with responseTerminator: implemented entirely in any-sdk (internal/anysdk/pagination.go, paging loop in public/providerinvokers/anysdkhttp/invoker.go), consumed by stackql via the invoker call in internal/stackql/execution/mono_valent_execution.go. Closed [FEATURE] Add a page_number pagination algorithm for APIs that signal completion via total_pages (or page-count comparison) any-sdk#91 via feat(pagination): add page_number algorithm for total_pages-based APIs any-sdk#94. Consumed since any-sdk v0.5.3-alpha05; current dep is v0.5.3-alpha11.

What is missing (this issue):

1. There is no stackql robot test or fixture for page_number anywhere in the repo (zero occurrences of page_number / responseTerminator under test/).
2. The mocked GraphQL pagination suite (test/robot/functional/stackql_graphql_pagination.robot) exercises only the default cursor_after strategy. keyset, offset and page_info have no SQL -> HTTP -> projection round-trip coverage.

Per AGENTS.md, black-box robot regression tests are the required evidence for user-visible query behaviour; any-sdk unit tests alone do not satisfy that for these features.

Test set A: REST page_number

Add a synthetic fixture under test/registry-mocked/src/ with a pagination block shaped like Cloudflare V4:

pagination:
  algorithm: page_number
  requestToken:
    key: page
    location: query
  responseToken:
    key: result_info.page
    location: body
  responseTerminator:
    key: result_info.total_pages
    location: body

Scenarios (mock endpoints in the flask tooling under test/python/stackql_test_tooling/flask/):

Select With Page Number Pagination Terminates When Page Equals Total Pages
    # GET /things?page=1 -> {result_info:{page:1, total_pages:3}, result:[A,B]}
    # GET /things?page=2 -> {result_info:{page:2, total_pages:3}, result:[C,D]}
    # GET /things?page=3 -> {result_info:{page:3, total_pages:3}, result:[E]}
    # Assert: 5 rows, exactly 3 requests.

Page Number Pagination Stops Immediately When Page Equals Total Pages At Start
    # GET /things?page=1 -> {result_info:{page:1, total_pages:1}, result:[A]}
    # Assert: 1 row, exactly 1 request.

Page Number Pagination Fails Cleanly When Terminator Field Absent
    # GET /things?page=1 -> {result:[A]} (no result_info)
    # Assert: terminates (no infinite loop); row returned or explicit error.

This test set doubles as verification of a residual risk: internal/stackql/execution/mono_valent_execution.go still carries its own token-only paging helpers (inferNextPageResponseElement / inferNextPageRequestElement, flagged !!TECH_DEBT!!) that do not know about page_number. If the mocked scenario pages and terminates correctly, the live path is confirmed to be the any-sdk invoker. If it loops or stops early, that is a real bug and this issue should be re-scoped.

Test set B: GraphQL pagination strategies

One mocked scenario per strategy, following the existing pattern in stackql_graphql_pagination.robot (native_test flask mock, --http.log.enabled wire assertions):

Select With Keyset Pagination Drives Forward And Terminates
    # Page 1: 2 rows; page 2: 1 row; page 3: 0 rows -> terminate.
    # Assert the _gt filter on the sort key advances per page.

Select With Offset Pagination Terminates On Short Page
    # Page size 2. Pages: 2 rows, 2 rows, 1 row (short) -> terminate. 5 rows total.

Select With PageInfo Pagination Terminates On hasNextPage False
    # hasNextPage true/true/false across 3 pages -> terminate after page 3.

The existing cursor_after scenarios must keep passing unchanged (back-compat guard).

Out of scope

• Any change to feature code in stackql or any-sdk (unless test set A exposes a live-path bug, which becomes its own issue).
• A mocked variant of the GraphQL response.transform test (live trevorblades coverage exists; a mocked twin is nice-to-have, not required here).
• REST link_header pagination improvements.

Acceptance criteria

• Mocked fixture and flask endpoints for page_number added under the existing test tooling.
• Test set A passes, including both negative scenarios.
• Test set B passes for keyset, offset and page_info.
• Existing cursor_after scenarios and the rest of the robot suite pass unchanged.

References

• stackql PR graphql enhancements #658 (d1f204e) - GraphQL transform + cursor config consumption.
• stackql PRs consume any-sdk v0.5.3-alpha08 (casing + schema_driven_xml) + robot coverage #678 (b51c514), fix: symtab registers snake display column names + robot coverage for AWS e2e casing/walker behaviours (any-sdk v0.5.3-alpha11) #679 (902c151) - any-sdk bumps to v0.5.3-alpha08/alpha11.
• [FEATURE] Add a page_number pagination algorithm for APIs that signal completion via total_pages (or page-count comparison) any-sdk#91 (feature request), closed by feat(pagination): add page_number algorithm for total_pages-based APIs any-sdk#94 - page_number implementation.
• test/robot/functional/stackql_graphql_pagination.robot - existing mocked GraphQL pagination suite.
• test/robot/integration-traffic-lights/stackql_traffic_light_integration_from_cmd_line.robot - live transform coverage.