Admin API/Portal Authentication

Is your feature request related to a problem? Please describe.
There is a desire to revamp the authentication scheme for the Admin API/Portal before it gets too ingrained. This proposal contains details on how to do this.

Describe the solution you'd like
Create the following tables:

• AdminUsers
• AdminGroups
• AdminPermissions
• GroupUsers
• GroupPermissions

AdminUsers will key off of the user's snowflake value and will have a single boolean value: IsSuperAdmin. If a user is in this table, they will be allowed to authenticate with the API or log into the admin portal. This alone does not permit them to perform any administrative actions.

AdminGroups will contain an assortment of user groups and their descriptions. A simple incrementing integer key will be sufficient. Each group should have a name and a description.

AdminPermissions will contain a selection of permissions. The name should be a PascalCase string of letters or numbers. This will be what is used within .NET to decorate particular endpoints for authorization purposes. The permissions should be seeded during migration and should not be editable through the admin API/portal.

GroupUsers associates a group id and a user id, such that filtering on a group id will list all users in that group and filtering on user id will list all groups the user is a member of.

GroupPermissions associates a group id with a permission id, such that filtering on a group id will list all permissions assigned to that group and filtering on permission id will list all groups with that permission.

The first user will be added via the CLI by the instance owner. The snowflake is a required argument and it will add the user to the AdminUsers table with IsSuperAdmin set true.

Once this user is in place, the user can sign in to the portal or use the API to add additional users, create groups, and assign permissions.

Additional context
Diagrams coming soon!
If not specified, assume the table has an auto incrementing int key.

Start by reviewing the existing Admin API, portal authentication, database schema, and CLI entry points; the issue does not name files or tests. Define how the five tables, seeded permissions, authentication, authorization, portal administration, and first-user CLI flow fit together, then verify the complete user and group permission lifecycle.