fix(bigquery): drop startIndex whenever a page token is sent

[abhishekacharya200]

Fixes #18601

RowIterator._get_next_page_response only removed startIndex from follow-up page requests when page_size was set. With only max_results and start_index, the server can still split the result into several pages (for example when a page would exceed the response size limit). The next request then sent both pageToken and startIndex, which the API rejects:

400 ... When using a page token, you cannot specify an arbitrary startIndex.

This drops startIndex whenever a page token is sent, regardless of page_size. The first request still carries startIndex, and the original params are not modified, so iterating the results again keeps working as before.

Added test_result_with_start_index_and_max_results_multi_page, which fails on main with the same pageToken + startIndex request from the issue and passes with this change. The full tests/unit suite passes locally (2396 passed), and black==23.7.0 reports no changes.

• Issue opened before writing the code (Big Query RowIterator offset error #18601)
• Tests and linter pass
• Code coverage does not decrease
• No docs changes needed

[gemini-code-assist]

Code Review

This pull request updates the logic for removing startIndex from query parameters during multi-page results in BigQuery. Instead of checking for page_size, it now removes startIndex when a page token is present, preventing conflicts when the server splits large results. A unit test was also added to verify this behavior. Feedback suggests improving readability by checking self.next_token is not None instead of checking if self._next_token is in params, as _next_token is a class attribute representing the parameter name string.

[parthea]

Thanks @abhishekacharya200!