Proposal: Move configuration to JSON to better support self-hosting

There's been a request to add a container image, I presume to support people want to use Stormbox for their own JMAP server.

To better support that, we could switch to configuring the frontend at run-time rather than build-time.

Context

Currently Stormbox is configured with VITE_* env vars which get baked into a build and deployed to Cloudflare pages.

Proposed behavior

For better reusability, we could configure via a config.json file that the frontend reads.

Example:

{
  "jmapServerUrl": "https://jmap.example.com",
  "oidcIssuer": "https://auth.example.com/realms/mail",
  "oidcClientId": "stormbox",
  "accountsUrl": "https://accounts.example.com",
  "appointmentUrl": "https://appointment.example.com",
  "sendUrl": "https://send.example.com",
  "senderAvatarProxyUrl": ""
}

Configuration files

We could check-in env-specific files:

 config/
 ├── development.json
 ├── stage.json
 ├── production.json

Deployment

During deploy, we'll place the appropriate config file at dist/config.json

Out of scope here / future work

• This refactoring will make it natural to later build a container image for each release where users can mount in their own config file. The container might also accept ENV vars that map 1:1 to config keys, like Ghost does
• We could also consider publishing a .zip file for each release that contains the built assets and config.example.json. This may be of interest to people who quickly checkout a release or run something simply from their laptop.

Start by tracing how the frontend currently consumes VITE_* environment variables and how deployment produces dist/. Review the proposed config/development.json, config/stage.json, and config/production.json files alongside the runtime dist/config.json placement. Done means the frontend reads the documented JSON configuration at runtime while preserving the listed environment-specific deployment behavior.