In #10990 I already tried to achieve this but noticed there are still case when this is not working. For example any request to SitesManager.getSiteFromId will overwrite any site information in Site::$infoSites.

Meaning a controller might do new Site(), then further down an API request, or the archiver does SitesManager.getSiteFromId and overwrites a previously enriched site. It is even more messy that at any point the data within new Site() might be changed by another API request or method that calls Sites::set*.

It is much better to instead keep the site in a non-static property when an instance is created and to always work on that data. This is much more reliable and what consumers expect. In theory, there could be a case that a site is deleted or updated via an API request, and then the data within Site->site is not updated automatically but this is not a problem for us.

Having this PR merged will make sure that when you change eg the name of a website with the event Site.setSites, it will appear correctly in the website selector and in the mobile app.

There are still more inconsistencies to tackle eventually. Eg all SitesManager.get* methods might trigger the Site.getSites event letting consumers change the site objects, but none of the APIs actually return the changed value. This is much harder to solve though and therefore not included in this PR