The Kubernetes deployment runs the split go-guess-web image, which is a plain
nginx serving static files and never ran an entrypoint. The theme service origin
is therefore never written into runtime-config.js there, so the page would always
read the empty default and theming would be silently inert in the cluster while
working in local runs. The combined root image already did this; the split one
now does too.
The script lives beside the frontend Dockerfile because that image's build
context is ./frontend, which cannot see docker/.
The chart passes THEME_BASE_URL to the web container rather than the API: it is
read by the browser, not by the service. It stays absent when unset, so a
deployment with no theme service renders exactly as before.
