GUI jobs with Wasabi destination still actually use S3

Please describe what you are doing to trigger the bug:
Create a new job with Wasabi destination in GUI.
In my case I run GUI as admin to create jobs that run in the service.
Using the EU instance of Wasabi.

Please describe what you expect to happen (but doesn’t):
Destination path should use protocol wasabi://

Please describe what actually happens (the wrong behaviour):
Destination path is both in GUI and in .duplicacy/preferences as s3://

I tried to manually change it to wasabi:// - CLI then asked me credentials again on first run and worked without problems. GUI did not work neither before nor after entering credentials in CLI. Most likely because if I understand correctly the credentials when running as admin are stored in registry while CLI stores them in a file

Other details: Win10 x64, latest Duplicacy version (2.1.2)

Yes, in 2.1.2 wasabi still uses the s3 backend. This will be fixed in 2.1.3.

If you run the CLI in an admin DOS prompt you might be able to get around this issue.

Yes, after changing the preferences file manually and running the CLI in admin prompt the credentials were also available for GUI.

Ok, I was a bit too fast in claiming that it works:
After running CLI as admin and entering the credentials I can indeed run the backup from GUI running as admin manually. This did not work previously as GUI running as admin was also missing credentials. Now they seem to be present.
But when the backup is done using the service then I still get errors about missing credentials in the logs and backup does not run. So it seems the service still needs them somewhere else.