So Update from my side:

TLDR: perform a Point in Time restore of an old backup where your DB is not corrupt yet and better also implement your own backup process :-)

After literally weeks of back and forth with the Azure Support team, at some point the product team was involved but also did not have a solution to fix the issues. Once the DB is in a corrupt state, the only fix that Azure Support came up with was to restore the the DB from a previous backup where the DB was not yet in a defective state and take it from there. Unfortunately since this "solution" was provided several weeks after the case has been opened, we did not have any backup anymore that did not contain the corrupted DB plus of course live goes on and the other databases got updated so it would have been a migration project with quite some effort to restore a backup on a new flexible server instance then merge all delta data from current state of the other DBs to the new instance then shut down the old instance and point all consumers to the new DB instance. We are very lucky that this happened to us in our DEV environment and not in Production, but certainly we learned not to use the Azure Portal UI to delete Databases anymore, since this was beginning of all the troubles.

It is a limitation of the flexible server that the customer does not get a superuser role that one has to be aware from the beginning when choosing PostgreSQL flexible Server. It is understandable on the one hand, that Azure wants to limit the damage the customer can do to the managed instance, but also it can lead to problems if you cannot properly manage the data and permissions in your own instance.