fix: prevent group loss when paginating checkIfUserHasGroups past 2 pages

[rasta-rocket]

What

checkIfUserHasGroups (used by okta_user_group_memberships create/read) declared its per-page slice outside the pagination loop and reused it across pages:

var nextUserGroups []*sdk.Group        // declared once
for resp.HasNextPage() {
    resp, err = resp.Next(ctx, &nextUserGroups)   // decoded into the same slice every time
    ...
    userGroups = append(userGroups, nextUserGroups...)
}

encoding/json does not allocate new structs when the destination slice already holds non-nil pointers - it follows the existing pointers and overwrites the structs in place. Since userGroups holds those same pointers, decoding page 3 silently rewrites the entries copied from page 2.

Why it matters

Any user with more than 400 group memberships (2 pages of the API's 200-per-page limit) triggers this on the third page onward. Groups the user is genuinely a member of vanish from the collected set, checkIfUserHasGroups reports them as missing, and resourceUserGroupMembershipsCreate's backoff.Retry exhausts with:

Error: user (<id>) did not have expected group memberships after multiple checks

...even though addUserToGroups already succeeded and the group assignment is correct in Okta. terraform apply fails deterministically every time for these users - it isn't a flaky eventual-consistency race.

This is the same bug class as #1542 (pagination wasn't looped at all), one layer deeper: the loop is correct, but the accumulation across iterations isn't.

Fix

Move the slice declaration inside the loop so each page decodes into its own freshly allocated slice:

for resp.HasNextPage() {
    var nextUserGroups []*sdk.Group   // fresh per iteration
    resp, err = resp.Next(ctx, &nextUserGroups)
    ...
    userGroups = append(userGroups, nextUserGroups...)
}

Testing

Added TestUserGroupMembershipsReadPaginationDoesNotDropGroups, a unit test (httpmock, no TF_ACC) that mocks a 3-page GET /users/{id}/groups response with the target group on page 2 and asserts it survives to the final result. Verified it fails on main (before this fix) with:

expected: "<user_id>"
actual:   ""

and passes with the fix applied. go vet and gofmt clean.

Reproduced against my company's real Okta org data with a local build - the failing users have 401-600 group memberships (3 pages), and the missing group falls in the corrupted range as predicted.

Cheers ☀️