Description

Consumes any-sdk v0.5.3-alpha05 and wires two of its three new GraphQL features through to stackql:

1. response.transform — stackql now extracts the operation's response.transform (type + body) and passes it to any-sdk's GraphQL reader, which applies the template to the raw response before the existing responseSelection.jsonPath projection. Lets specs flatten deep GraphQL responses into top-level columns without JSON_EXTRACT in SQL.
2. Pluggable GraphQL pagination strategies (cursor_after, keyset, offset, page_info) — stackql now builds a graphql.CursorConfig from the new accessors on the x-stackQL-graphQL.cursor extension (strategy, format, terminateOnJsonPath, pageSize) and hands it to any-sdk via the new NewStandardGQLReaderFull constructor. Empty/absent fields default to cursor_after, so existing GraphQL providers are byte-identical to before.

The single dispatch site in graphql_single_select_acquire.go swaps from NewStandardGQLReader to NewStandardGQLReaderFull. The new field-extraction logic lives in two helpers (extractGraphQLResponseTransform, buildGraphQLCursorConfig) to keep Build() under the cyclomatic-complexity threshold.

The third any-sdk feature (algorithm: page_number REST pagination) is deliberately not wired in this PR — see Tech Debt below.

What's in this PR

Type of change

• Bug fix (non-breaking change to fix a bug).
• Feature (non-breaking change to add functionality).
• Breaking change.
• Other (eg: documentation change). Please explain.

Issues referenced.

Evidence

• go build ./... — clean.
• go test -timeout 120s --tags "sqlite_stackql" ./internal/stackql/... ./stackql/... — all packages pass (main suite ~30s).
• golangci-lint run ./... (v2.5.0, matches .github/workflows/lint.yml) — 0 issues.
• New robot test GitHub SAML Identities Select GraphQL With Response Transform reuses the existing SAML mock and asserts the same expected output as the existing test, but using the SQL select guid, saml_id, github_login ... order by github_login asc — i.e. flat columns served by the transform rather than via JSON_EXTRACT. Existing GitHub SAML Identities Select GraphQL is untouched and proves back-compat of the default cursor_after path.
• Transform template rendered correctly against a representative GraphQL payload during local validation (throwaway test; not included in the diff).

Checklist:

• A full round of testing has been completed, and there are no test failures as a result of these changes.
• The changes are covered with functional and/or integration robot testing.
• The changes work on all supported platforms.
• Unit tests pass locally, as per the developer guide.
• Robot tests pass locally, as per the developer guide.
• Linter passes locally, as per the developer guide.

Variations

• Robot tests run locally: not run end-to-end on my workstation (robot framework isn't installed in this WSL env). The new test follows the same pattern as the adjacent GitHub SAML Identities Select GraphQL test and reuses its expected-output fixture; CI is the source of truth here.
• Coverage scope: this PR ships a robot test for response.transform only. The three new cursor strategies (keyset / offset / page_info) are covered by any-sdk's own unit tests (TestRead_Keyset, TestRead_Offset, TestRead_PageInfo in pkg/graphql/graphql_test.go); the stackql change for those is pure config plumbing with no branching logic to exercise, and back-compat of the default cursor_after path is covered by the unchanged existing SAML test.

Tech Debt

any-sdk v0.5.3-alpha05 also adds algorithm: page_number REST pagination (Cloudflare V4 / Atlassian / ServiceNow shape — termination by comparing current page to total pages rather than waiting for an empty next-page token). The internal logic exists in any-sdk and is consumed by the anysdkhttp invoker, but the public formulation.OperationStore interface does not re-export GetPaginationAlgorithm() or GetPaginationResponseTerminatorTokenSemantic() — both of which stackql's local SELECT-pagination loop (internal/stackql/execution/mono_valent_execution.go::page()) needs in order to dispatch on the algorithm.

Wiring page_number from stackql therefore requires a small follow-up any-sdk PR to lift those two getters through the public wrapper, a re-bump here, and a ~30-line dispatch + 3 robot tests in stackql.

Tracking issue (to be filed in any-sdk): link TBA — covers adding GetPaginationAlgorithm and GetPaginationResponseTerminatorTokenSemantic to public/formulation/{interfaces,wrappers}.go.