fix: advance the v2 runs/query cursor in the request body

[Quentin Brosse (QuentinBrosse)]

Description

POST /api/v2/runs/query reads cursor from the JSON body, but langsmith-go's generated ItemsCursorPostPagination.GetNextPage applies option.WithQuery("cursor", next) — a URL query parameter the server ignores. Every "next page" request therefore refetched page 1, so queryRunsV2 accumulated the same 100 runs until it hit the caller's limit (1000 for trace get, i.e. 10 duplicated pages) and never reached the later runs. queryRunsV2 now pages explicitly with Runs.QueryV2, setting params.Cursor (a body field) from each response's next_cursor, mirroring the existing v1 queryRuns helper, and stops if a cursor ever repeats so an unbounded limit (thread list passes math.MaxInt32) cannot loop forever.

Affects every v2 run query that needs more than one page: trace get, trace list --show-hierarchy, trace export, run list, thread list.

Note: the underlying SDK bug still needs an upstream fix (body-cursor paginators in langsmith-go should emit WithJSONSet, not WithQuery); it also affects the v1 CursorPagination auto-pager, which this CLI does not use.

Test Plan

• go test ./internal/cmd -run TestQueryRunsV2 — new tests cover body-cursor advancement, stopping at the limit, and the repeated-cursor guard; the first one fails on main with page 1 duplicated
• langsmith trace get <trace-id> --project <p> against a trace with >100 runs returns each run once with an accurate run_count

Made by Open SWE