Actually, as of when I write this post, we have two license keys available for anyone with a paid edition. One is a prod license and the other is a non prod license. The latter is a good fit for testing, CI, etc.
You are correct. The verified flag exists on the corresponding user and the registration. You could optionally use the "verify registration" templatefor this purpose.
If you then ignored the verified: false flag on the registration in your code, it should not impact you.
Another option would be to listen for the user.registration.create event and then fire off an email on your end, or call the Email Send API to send a pre-made FusionAuth email template as a welcome event: https://fusionauth.io/docs/v1/tech/apis/emails/#send-an-email
I thought that might be a possibility and later tried a t3a.small (vs. t3a.micro) in a new install. So far that's has been working. (As far as anything else on the box - nothing. I like to dedicate at least one VM per major system.)
There's no way to create such a super admin account that can't be modified in FusionAuth.
Options I can think of to achieve something similar:
make sure you have database backups (a good idea anyway) and recover from your last backup if an admin deletes/locks the primary admin account. Or just investigate the FusionAuth database such that you can flip the bit in there if anyone ever locks the primary admin account.
create a second tenant and create a tenant scoped API key. Then build whatever user management tooling you need using that API key. The super user will remain untouched and inaccessible in the default tenant.
limit people to the roles that they need and never provide anyone with the user_deleter or user_manager role. The user_support_manager role may be helpful to you: https://fusionauth.io/docs/v1/tech/core-concepts/roles/
Only the last one allows users other than the superadmin to access the FusionAuth admin UI.
Is there a way to get the actual error via the FusionAuth admin dashboard?
You can check the event logs and the system output if you have access to the logs, but I don't believe there's a lot of debugging info available for that particular path.
So, this appears to be a limitation of Facebook. Here are the API docs from Facebook which have no mention of how long the image URL returned if you pass redirect=0 is good for.