Pagination::next_page() sends ?next_page= instead of page_token, so manual pagination 400s or loops forever

[sneg55]

Pagination::next_page() sends ?next_page= while the API and every stream call site use page_token, so manual pagination loops or 400s

Context: API Makeathon participant. Found while reviewing the pagination trait; verified against the generated stream call sites.

The public Pagination trait's next_page() method (documented as "Modify a request to get the next page") appends ?next_page=<token>, but the API's page parameter is page_token. Every generated *_stream helper uses the correct name, so the two paths disagree.

Evidence

kittycad/src/types.rs: all 10 ResultsPage impls call self.next_page_with_param(req, "next_page") (for example at lines 2030 and 2243). Meanwhile every generated stream call site uses page_token, e.g. kittycad/src/api_calls.rs:191/364/551 and kittycad/src/orgs.rs:274 all call next_page_with_param(request, "page_token"), matching the OpenAPI spec.

Concrete failure

A user who paginates manually via the exported types::paginate::Pagination trait (rather than the *_stream helpers, for example because they need control at the async boundary or are on a target where the streams are cfg'd out) sends ?next_page=<token>. The server does not recognize it, so it either 400s or returns page one repeatedly with next_page still Some, an infinite loop that bills an API call every iteration.

Verify

Build a reqwest::Request, construct any ResultsPage with next_page: Some("tok".into()), call next_page(req), and assert the URL query. It is next_page=tok; it should be page_token=tok.

Suggested fix

Change the next_page_with_param(req, "next_page") calls in the ResultsPage impls to "page_token", matching the stream helpers and the API.

Environment

Reviewed against the current main of KittyCAD/kittycad.rs.