Fix idempotent Google Workspace user status updates

[cxcollins]

Summary

• avoid updating an account when its Google Workspace suspension state already matches the requested value
• add a regression test for disabling an already suspended account through update_user_status

Fixes: IGA-1362

Test plan

• go test ./...
• make lint

[linear-code]

IGA-1362

[github-actions]

🟡 Suggestion: This only covers the short-circuit path. A regression that made updateUserStatus always return early (e.g. the guard becoming unconditional) would still pass. Consider adding a case where the requested state differs from the current one and asserting putCount == 1 plus the resulting Suspended value, mirroring TestDisableEnableUser_IdempotentAndPayload.

[github-actions]

Connector PR Review: Fix idempotent Google Workspace user status updates

Blocking Issues: 0 | Suggestions: 1 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base 90e5345686e8.
Review mode: full
View review run

Review Summary

Scanned the full PR diff (pkg/connector/actions.go, pkg/connector/actions_test.go) for security and correctness. The change adds a pre-read of the user via GetUserForProvisioning and short-circuits updateUserStatus when the requested is_suspended value already matches, mirroring the existing disableUserActionHandler/enableUserActionHandler pattern; errors are wrapped with %w and the google-workspace: prefix, the extra Users.Get call needs no scope beyond the write scope already required for the PUT, and no dependency manifests changed. No blocking issues found; one test-coverage suggestion.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

• pkg/connector/actions_test.go:255 - the new test only asserts the no-op path; add a case where the requested status differs so the PUT path stays covered.

Prompt for AI agents

Verify each finding against the current code and only fix it if needed.

## Suggestions

In `pkg/connector/actions_test.go`:
- Around line 239-258: TestUpdateUserStatus_IsIdempotentForSuspendedUser only exercises
  the short-circuit branch of updateUserStatus (already-suspended user, expect zero PUTs).
  A regression that made the early return unconditional would still pass. Add a second
  case in the same test (or a sibling test) that starts from Suspended false, calls
  updateUserStatus with is_suspended true, and asserts state.putCount == 1 and the user
  ends up Suspended, mirroring the structure of TestDisableEnableUser_IdempotentAndPayload.

[github-actions]

No blocking issues found.