[BUG]: fix lowercase permadiff team members

[deiga]

Resolves #3533

---

Before the change?

• username lower casing is causing permadiff

After the change?

• fixes permadiff by storing username as lowercase in state

Pull request checklist

• Schema migrations have been created if needed (example)
• Tests for the changes have been added (for bug fixes / features)
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

• Yes
• No

---

[github-actions]

👋 Hi, and thank you for this contribution!

This repo is maintained by GitHub and community members on a best-effort basis. We'll get to this as soon as we can.

You can help us prioritize by joining the discussion on open issues and PRs, sharing details on the changes you need, and reviewing other contributions.

---

_{🤖 This is an automated message.}

[Copilot]

Pull request overview

These provider review instructions are being used.

Findings

1. MEDIUM — Missing regression test for the permadiff fix
   • File reference: github/resource_github_team_members.go:66-79
   • Why this is a problem: The fix relies on new schema normalization behavior (Set hashing + StateFunc) to prevent case-only diffs; without a targeted test, this bug can regress silently (similar to how case handling already has coverage for github_team_membership).
   • Suggested fix: Add an acceptance test for github_team_members that applies with one username case, then flips case and asserts a no-op plan (and/or verifies stored state uses the canonical lowercase form).

This PR addresses the github_team_members perpetual diff caused by username case normalization, by canonicalizing usernames to lowercase for state and set element identity.

Changes:

• Canonicalize members.username to lowercase via StateFunc.
• Make members set identity case-insensitive by hashing the lowercase username in a custom Set function.

[stevehipwell]

I think changing Set would technically be a breaking change, but I think we ought to do it anyway as any breaking issues would be catching incorrect usage.

RE the username casing, I think that we should keep the diff suppression pattern as that way we don't lose any of the input data.

[stevehipwell]

@deiga FYI you should be able to add acceptance tests with alternative cases using the existing users.

[stevehipwell]

I don't think we need this?