feat(admin): Move pending users to their own tab and add indicator badge

[ArcticWarmth]

Summary

This PR is helps to eliminate user confusion by separating the pending registrations out into their own page. It serves as a decent starting point to #1105

What changed:

UI

• Added new page under admin that displays pending registrations (admin/pending-users)
  • Added badge on sidebar displaying amount of pending registrations
• Removed pending registrations from Instance Config page

Backend

• Updated OpenAPI schema to reflect requirement for new ACL and new endpoint
• Updated admin controller to return pending user count so it can be found using an auth context in the admin panel

ACLs

• Added new USER_APPROVE_ACCOUNT ACL which is now required to approve/reject users

Endpoints

• New API endpoint /admin/pending-registrations/get
  • Get pending user registrations in an array
  • Requires USER_APPROVE_ACCOUNT ACL
  • Added to allow for user who only has the new ACL added in this PR to view pending approvals
• Update endpoint to new URL
  • /admin/instance-config/pending-registrations/approve -> /admin/pending-registrations/approve
  • /admin/instance-config/pending-registrations/reject -> /admin/pending-registrations/reject

Why it is correct:

• User cannot view new tab in admin interface without the required ACL
• No new data is passed around except the raw number of pending users to maintain security
  • Null safe

Risk

This PR is low to medium risk as it does touch the auth middleware for the admin panel but changes are minimal

Verification

Tests run:

fluxer_api/src/api/admin/tests/

Prior to PR

10 failed | 236 passed (246)

Code in PR

10 failed | 236 passed (246)

fluxer_admin/

 All tests pass

Manual checks:

• Logged in as user without ACL for approving users
  • sidebar tab correctly hidden, shown when user has correct ACL
• Button to approve/deny were manually tested and working
• Badge displays correct number of pending registrations

Screenshots or recordings:

Checklist

• I understand every change in this PR.
• I can explain what it does and why it is correct.
• I disclosed any LLM coding help below.

LLM Disclosure

• No LLMs were used in any capacity

[blstmo]

In the sidebar badge, it’s doing auth.admin_user.as_ref().unwrap() and style=("float:right"). Layout already has auth and usually just passes derived values into the sidebar (like admin_acls / inspected_voice_region_id). Could this pass an Option count instead, and use Tailwind rather than float?

[blstmo]

pending_guilds_users_page should be something like pending_users_page to match the naming schema of the rest of the admin system.

[ArcticWarmth]

Thanks for the comments. This was something I worked on and off over several days and I must have missed a few things when going back reviewing the diffs. Working to resolve now

[blstmo]

Also you may want to check how your doing API endpoints I would need to double check this as I have forgotten how the ACL system works but I am pretty sure this feature wont work if the admin doesn't have both INSTANCE_CONFIG_UPDATE and USER_APPROVE_ACCOUNT because of the endpoint you use to pull the information from which also returns the full instance config.
If you check it and it works fine when the user only has USER_APPROVE_ACCOUNT then its not a massive issue but the system would be cleaner if it was moved to its own endpoint and then removed off instance config.

[blstmo]

A few fixes and checks to make sure no issues arise comments made in code for you.
Along with I would suggest checking how redirects are handled for the functions as I am pretty sure it will redirect back to instance-config in some edge cases so I would suggest trying to move all of the handlers and functions around this away from instance config for code maintainability's sake and to avoid any future permission clashes.

Apologies for the less detailed review its late at night.

[ArcticWarmth]

Ready for re-review when someone gets time