Scalability meta issue

This issue is meant to provide actionable tasks to improve scalability in specialised, highly volatile hosting environments.

- [ ] The renderer is stored and cached to local disk. flarum/issue-archive#154
- [ ] the `users.avatar_url` string length is too short disallowing the use of CDN's
- [ ] `migrations` table has no auto increment primary key ID on some DB's this causes errors and fails migration completely, I also remember faintly some db tools dislike this and remove checkboxes (phpmyadmin?)
- [ ] The DatabaseSessionHandler requires knowledge of the actor. As user nor request isn't available from the container one cannot override the `session.handler` easily; right now fixed by binding the actor into the container.
- [ ] Overriding any of the compilers (because you want to override the revision generation), requires you to override the Assets class which you cannot override easily. It is possible using `extend` but then you also need to hit the original `FrontendServiceProvider` to retrieve `addBaseCss` twice (css, localeCss).
- [ ] `logoUrl` and `favIconUrl` both need to start using a similar implementation like the avatar_url of User. Right now the only way to override these is by mutating the attributes in the ForumSerializer.
- [ ] It would be helpful to be able to add migrations from the local `extend.php`. Right now my default go to is to create a custom command that replicates our own migration command, but with a different path.
- [ ] cache clearing won't work across nodes
- [x] `posts.number` calculated on php backend flarum/framework#3350
- [ ] locales catalogue is stored on disk to storage/locale, on scaled nodes this file isn't available and thus references are not loaded
- [ ] queue jobs `$queue` property is ignored, only setting the queue name through dispatching works
- [ ] the DatabaseSettingsRepository is wrapped inside a MemoryCacheSettingsRepository that keeps settings in memory, it would be better to inject the configured cache and use that instead of the static property
- [ ] the queue daemon/worker does not have the cache store injected and as such cannot restart based on the RestartCommand, which also isn't yet part of Flarum
- [x] flarum/framework#3231
- [x] flarum/framework#3234
- [x] The js (forum, admin and locale)/css are stored using `something-.filetype`, when invalidating cache on one node and that node stores a new version into a CDN, users on other nodes will require to reload the page to retrieve the latest rev-manifest to load the right files. In the meantime their pages might break. A solution is to use the revision/hash as query param thus auto invalidating client-side cached files, but also providing a fallback in case the revision is incorrect.

This is a broad meta issue covering caching, database migrations, sessions, assets, queues, and scaled-node behavior rather than one change. Start by reviewing the unchecked items and the referenced framework issues, including flarum/issue-archive#154, then split one concrete task into a focused issue. Done means each selected task has a defined scope and its own verifiable change.

Written by the indexing model from the issue text.