Fix for plugin auto-approval logic

[Xpirix]

Description

Closes #291

Cc @timlinux @3nids @Gustry @Guts

Currently, the auto-approval logic has issues because it approves both versions created by trusted users and new versions of plugins that are already approved. This is critical because, as discussed with @timlinux, we should only trust users, not plugins.
This PR will address this issue by only applying auto-approval for plugins from trusted users. For token-based uploads, it will check the permissions of the token creator (because request.user will be an AnonymousUser).

This will likely modify (fix) the workflow and add more tasks to the plugins approver (Cc @NyakudyaA) because all new versions from untrusted users will require approval.

Author's checklist

• I have read the contributing guidelines and my pull request follows them.
• my commits tend to comply with Conventional Commits; so they are descriptive and explain the rationale for changes. Messages and description are self-explanatory to make the git log a readable story of the project.
• I have added tests that prove my fix is effective or that my feature works.
• I have added necessary documentation (if appropriate).
• commits which fix bugs include Fixes #11111 at the bottom of the commit message.

Tip

If you forgot to do this, don't be shy and write the same statement into this text field with the pull request description.

AI tool usage

• AI tool(s) (Copilot, Claude, or something similar) supported my development of this PR. See our policy about AI tool use. Use of AI tools must be indicated. Failure to be honest might result in banning.

Reviewer's checklist

• I remember to check the "Author's checklist" above and ask the author to update the PR description if any of the items are not checked.
• I remember that welcoming new contributors is more important than nitpicking on code style. I will be kind and respectful in my review comments.

[Guts]

I like the idea of updating the plugin approval process, especially the “fast-track” option.

I think this was discussed a while back on a QGIS mailing list, but I can't find any record of it (I can't wait for the switch to Discourse...). Do you have a record of your discussions with Tim regarding the various details?

Generally speaking, is it possible to tell if a user has this self-approval capability? I mean, with something visual on its profile page? I get a look on my own (https://plugins.qgis.org/plugins/user/geojulien/) and I can't see nothing but I'm not sure I'm looking at the right place (since the page title is "All plugins - QGIS Python Plugins Repository").

I also think this is an opportunity to document this mechanism in more detail on https://plugins.qgis.org/docs/approval.

[timlinux]

For me I think it is better even if I have approval rights for the process to be split into two steps:

1. Upload plugins and it is available but not approved
2. I can click on the thumbs up to approve or use an API call to approve the plugin

I want to avoid the situation where plugins are uploaded and published in one step. Or I should have a 'Publish immediately' checkbox on the upload form.

[Guts]

In that case, it would be consistent to clearly stipulate if a given plugin's version has been approved manually and when (and by who?) or not.

[Xpirix]

Do you have a record of your discussions with Tim regarding the various details?

Sorry, it was just a verbal discussion during a meeting. The main reason is that this could lead to security vulnerabilities and issues.

Generally speaking, is it possible to tell if a user has this self-approval capability? I mean, with something visual on its profile page? I get a look on my own (https://plugins.qgis.org/plugins/user/geojulien/) and I can't see nothing but I'm not sure I'm looking at the right place (since the page title is "All plugins - QGIS Python Plugins Repository").

I don't think we have a profile page (yet). It could be a future enhancement.

I also think this is an opportunity to document this mechanism in more detail on https://plugins.qgis.org/docs/approval.

Sure, thanks for the suggestion. I'll implement that.