What about squadcal.org?

It's an interesting question. Today we use squadcal.org as the default on native. One advantage of this is that it avoids any using web.comm.app for both serving the web app and for my keyserver. Using squadcal.org here would make it easier to say "web.comm.app just serves the web app", which is perhaps a follow-up task to the "separate web and landing from keyserver" goal. However, I could imagine there might be CORS issues or something if a page loaded from web.comm.app is sending requests to squadcal.org.

There a task for CORS already (there isn't an explicit task for migrating to squadcall because I considered it a part of ENG-4756 but I haven't broken it into smaller tasks yet). In any case I think this should be done as separate to this diff.

This is a significant regression that makes it impossible to run a staging environment for the keyserver for testing purposes. It appears that your changes make it impossible to host the Comm web app on any domains other than web.comm.app

Then again, not clear how this should work in a multi-keyserver world, where keyserver and web are separated...

it impossible to run a staging environment for the keyserver for testing purposes

Are we doing something like this currently, or do you mean the general staging environment that we had been working towards?
After ENG-5153 (updating the urlfacts) this will be changed to point to squadcal so it's not obvious what would the staging web app point to. The easiest fix would be to just introduce some env variable with keyserver url or something like this.

But if it's not immediately needed, than this should get handled automatically in a multi-keyserver world if I understand everything correctly. There will be some discovery service that keyservers can register with, and from which clients can get information about available keyservers and connect to them (ENG-4135).

Are we doing something like this currently,

Yes, sometimes I need to test things in a publicly-addressable way, so I've set up a mirror of Comm (with an empty database) at comm.domains. So far I've only had two cases where I've needed this: primarily testing SIWE, but also recently I wanted it for testing master against an old version of Safari via an online tool.

There will be some discovery service that keyservers can register with

We've talked about this, but heads-up that in terms of sequencing, I'm thinking of that one as a sort of a "follow-up" to the multi-keyserver launch... we could launch with the expectation that users input keyserver URLs manually.

The easiest fix would be to just introduce some env variable with keyserver url or something like this.

I think this would be a good idea, but we should use getCommConfig for it. In the cases I've listed above, I actually didn't need a staging keyserver, just a staging web app / landing page. It would've worked fine if not for the CORS issues that prevented the staging web app from loading (it crashes trying to access the prod keyserver).