Case sensitivity in nextstrain.org usernames and emails

This came up [today](https://bedfordlab.slack.com/archives/CBVHPFMGX/p1762795793521219) for nextflu-private and also [earlier](https://bedfordlab.slack.com/archives/CBVHPFMGX/p1760028021726709) for wadoh-private, so I figured it's worth a short discussion to potentially improve things. ## Background Usernames and emails in our Cognito user pool are case sensitive¹, meaning it is valid to have two users with usernames `john.doe` and `John.Doe`, and similarly with emails `john.doe@example.com` and `John.Doe@example.com`. Technically, email addresses are cases sensitive, but [it's complicated](https://stackoverflow.com/a/34095774) and it seems like many major email providers treat them as case insensitive when receiving. ¹ _I think this was [simply the default](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-case-sensitivity.html#:~:text=user%20pools%20defaulted%20to%20case%20sensitive) when the user pool was created in 2019, though it could have been intentional?_ ## Possible solutions In practice, I don't think most users would benefit from having two usernames/emails with different casing, so we should try to avoid such situations. 1. ⛔️ Use a case-insensitive user pool. - It's [not possible](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-case-sensitivity.html#:~:text=Because%20of%20potential%20conflicts) to change a case-sensitive user pool to case-insensitive. The workaround of migrating to a new user pool seems overkill. 2. Automatically flag case-insensitive duplicates before creating the members in Cognito. - This is well-suited for [#987](https://github.com/nextstrain/nextstrain.org/pull/987). 3. Automatically lowercase usernames and emails in `scripts/provision-group`. - This avoids the need for [#987](https://github.com/nextstrain/nextstrain.org/pull/987), but I think it's too automatic and makes a broad assumption that everyone wants lowercased usernames and emails.