feat: Adds a Docker Build for the Web Client

[luthes]

This adds a multi-stage docker build for the web client. This was missing in the self-hosted compose (or at least was using the old UI).

• Multi stage Dockerfile - Builds a nice small alpine image with all the static output
• inject.js - Vite bakes env vars at build time, so I had to replace these (this also helps with multi-env without having a ton of different builds. One image, any environment).
• Github Actions: CI for the docker builds. I just noticed there's no arm64 in the docker builds and I saw other builds with it, I can add it if needed.

Just a quick bit on the inject.js script, that runs at container startup and copies the built dist/ to dist_injected/, does a find and replace of the placeholder strings with the actual env vars, and serves the result, but the original dist isn't touched, so containers restart cleanly.

...Or do they. Now that I write that, I might have over-engineered that bit, and it only needs to do the replace, any container/pod restarts would just restore the original dist/. Let me know which direction you'd want to go with that, and I can modify it. The replace needs to happen regardless. Maybe it's useful to keep the original around 🤷

You can test it though:

• docker build -t for-web .
• docker run -e VITE_API_URL=https://api.stoat.chat -e VITE_WS_URL=wss://ws.stoat.chat -p 5000:5000 for-web
• Verify env vars are injected in served JS

[luthes]

I was just reading over the other Docker PR. I think the dist_injected directory actually helps (solves?) the security issue brought up in this comment, and the one below it. Or at least is an implementation of the tmpfs that was talked about there.

I am not sure that either Nginx + SSI or the env inject approach are any more secure than the other. If an attacker gets access to the file system, both methods will have a writable filesystem they can access. I'm not a security expert, but it doesnt' seem much different if they get container access in one vs. the other.