fix(fleetcontrol): add missing cursor to getEntitySearchQuery

[ShaneLillieNR]

Summary

GetEntitySearch(cursor string, query string) in pkg/fleetcontrol accepted a cursor parameter that was a silent no-op: the generated getEntitySearchQuery GraphQL document only declared $query: String! and called entitySearch(query: $query,) — it never declared $cursor and never passed cursor: $cursor to the entitySearch field. The vars map set "cursor": cursor, but since the query text never referenced $cursor, the value was dropped before the request ever left the client. Every call re-fetched page one regardless of what cursor was passed in.

This is the exact same bug already found and fixed for GetFleetMembers in 93b8a99 ("fix(fleetcontrol): add missing cursor and fix cursor type in getFleetMembersQuery", #1394). That fix added include_arguments: ["cursor"] for the fleetMembers endpoint in .tutone.yml; the equivalent block for entitySearch was missing it.

Changes

• .tutone.yml: add include_arguments: ["cursor"] to the entitySearch endpoint under the fleetcontrol package's ["actor", "entityManagement"] queries block.
• pkg/fleetcontrol/fleetcontrol_api.go: getEntitySearchQuery now declares $cursor: String, and passes cursor: $cursor, to entitySearch(...). Applied by hand rather than a full tutone generate — the live NerdGraph schema has drifted substantially since the last full regen, and running it here would have pulled ~16k lines of unrelated changes across 60 files (and even broken an unrelated package due to a type-as-identifier codegen bug in entityrelationship_api.go). The diff here mirrors exactly what 93b8a99 produced for GetFleetMembers.
• GetEntitySearch/GetEntitySearchWithContext: cursor changed from string to *string, matching the same non-Tutone-covered change 93b8a99 made for GetFleetMembers (the API expects null for "no cursor", not an empty string).
• pkg/fleetcontrol/fleetcontrol_integration_test.go: updated the 3 existing GetEntitySearch("", ...) call sites to pass nil.
• pkg/fleetcontrol/entity_search_unit_test.go (new): mocks the NerdGraph endpoint and asserts the actual JSON request body sent over the wire includes the cursor value (and that a nil cursor sends null), verifying the fix at the wire level rather than just via generated code inspection.

No types.go changes were needed — EntityManagementEntitySearchResult already has NextCursor.

Surveyed the rest of fleetcontrol_api.go for other queries with the same dead-cursor bug: GetEntity fetches a single entity by ID and correctly has no cursor; GetEntitySearch and GetFleetMembers are the only two paginated queries in this package, and both are now fixed.

Verification

• go build ./..., go vet -tags unit ./..., go vet -tags integration ./... all clean.
• golangci-lint run ./pkg/fleetcontrol/... — 0 issues.
• go test -tags unit ./pkg/fleetcontrol/... — passes, including the new unit test.
• Verified against live NerdGraph: called GetEntitySearch(nil, "type = 'FLEET'"), took the returned nextCursor, called again with that cursor — page 2 returned a different set of entities and a new cursor, confirming the cursor now actually advances pagination against real data (not just a mocked assertion).

Context

Discovered while fixing a pagination bug in newrelic-cli's fleetcontrol fleet search command. That CLI-side fix is blocked on this PR merging and a new newrelic-client-go release.

Test plan

• go build ./...
• go vet -tags unit ./... / go vet -tags integration ./...
• golangci-lint run ./pkg/fleetcontrol/...
• go test -tags unit ./pkg/fleetcontrol/...
• Live NerdGraph pagination check (ad hoc, not committed)

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 32.97%. Comparing base (5ed5d8b) to head (93cb87f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1442      +/-   ##
==========================================
+ Coverage   32.39%   32.97%   +0.57%     
==========================================
  Files         148      148              
  Lines        6939     6939              
==========================================
+ Hits         2248     2288      +40     
+ Misses       4480     4435      -45     
- Partials      211      216       +5     

Flag	Coverage Δ
integration	0.21% <ø> (?)
unit	32.75% <ø> (+0.36%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[pranav-new-relic]

Hey @ShaneLillieNR, thank you for having this fixed, I think this certainly does look good, just that the unit test is a li'l fancy (unlike the unit tests in the rest of the client), but I get why, so I think that's fine (we might want to streamline this later sometime - I'll take a detailed look too) :)

The only double check I'd like you to perform is to test this change with the expected consumer of this change (e.g. the Terraform Provider, or the CLI where you'd like to enable this) so we're sure nothing breaks there. I'm sure there must be a companion PR to enable this (or I'd like you to create one, to fix this as needed) so you might want to test changes in the consumer with this PR and we're sure nothing breaks (it ideally should not :)) and that should give us a 🟢 to merge this.

[ShaneLillieNR]

Hey @ShaneLillieNR, thank you for having this fixed, I think this certainly does look good, just that the unit test is a li'l fancy (unlike the unit tests in the rest of the client), but I get why, so I think that's fine (we might want to streamline this later sometime - I'll take a detailed look too) :)

The only double check I'd like you to perform is to test this change with the expected consumer of this change (e.g. the Terraform Provider, or the CLI where you'd like to enable this) so we're sure nothing breaks there. I'm sure there must be a companion PR to enable this (or I'd like you to create one, to fix this as needed) so you might want to test changes in the consumer with this PR and we're sure nothing breaks (it ideally should not :)) and that should give us a 🟢 to merge this.

Hi @pranav-new-relic I think newrelic/newrelic-cli#1874 should cover what you're looking for? We can cover the exactly details on that when we get there but I think it's enough to prove out that the changes here are good?

[ShaneLillieNR]

newrelic/terraform-provider-newrelic#3171 is a similar PR but for updating the Terraform provider