fix(docker): runtime API-base override so served deployments reach the backend (#174)

Docker users reported Settings -> Engines failing with 'Failed to load engines:
Failed to fetch'. Two problems: (1) the two API-base resolvers diverged
(client.ts honored VITE_API_URL; apiBase.ts honored VITE_OMNIVOICE_API), and
the docs documented VITE_OMNIVOICE_API -- which the Engines request path
ignored; (2) VITE_* is inlined at BUILD time, so a prebuilt ghcr.io image has
no working runtime override at all for reverse-proxy / split-origin deploys.

- backend: when OMNIVOICE_PUBLIC_API_BASE is set, inject it into index.html as
  window.__OMNIVOICE_API_BASE__ (core/spa_inject.py; validated to a plain
  http(s) URL so it can't break out of the <script>). Unset (default) ->
  StaticFiles serves index.html untouched (same-origin, zero overhead).
- frontend: both resolvers (client.ts _resolveApiBase + utils/apiBase.ts) now
  read the runtime global FIRST, then VITE_OMNIVOICE_API/VITE_API_URL, then
  fall through to same-origin. client.ts also strips trailing slashes and
  recognises __TAURI_INTERNALS__ (parity with apiBase.ts/external.ts).
- docs: docker.md + troubleshooting.md document OMNIVOICE_PUBLIC_API_BASE as the
  runtime override that works on the prebuilt image (the old VITE_OMNIVOICE_API
  docker run -e example never worked -- build-time inlining).
- tests: spa_inject helpers (inject + URL validation/breakout); resolver
  precedence for the runtime global + VITE_OMNIVOICE_API in both test files.

Default same-origin behavior is unchanged on every platform; override is opt-in.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/install/docker.md

@@ -63,18 +63,27 @@ services:
       - "0.0.0.0:3900:3900"   # ← was 127.0.0.1:3900:3900
 ```
 
-The OmniVoice frontend uses `window.location.host` for its API base when no
-explicit override is set, so opening the UI from `http://<lan-ip>:3900` Just
-Works for both the page load *and* the media-preview requests it kicks off
-afterwards. If you front the app with a reverse proxy and the API and UI
-land on different origins, pin the API base explicitly:
+The OmniVoice frontend defaults to the **same origin** the page was served
+from, so opening the UI from `http://<lan-ip>:3900` Just Works for both the
+page load *and* the API/media requests it makes afterwards.
+
+If you front the app with a **reverse proxy** and the API and UI land on
+different origins, pin the API base explicitly. Use **`OMNIVOICE_PUBLIC_API_BASE`**
+— a *runtime* env var the backend injects into the page, so it works with the
+prebuilt image via `docker run -e` (the older `VITE_OMNIVOICE_API` is inlined at
+*build* time and cannot be set on a prebuilt image):
 
 ```bash
-docker run -e VITE_OMNIVOICE_API=https://api.your-host.example \
+docker run -e OMNIVOICE_PUBLIC_API_BASE=https://api.your-host.example \
   -p 0.0.0.0:3900:3900 \
   ghcr.io/debpalash/omnivoice-studio:latest
 ```
 
+> `OMNIVOICE_PUBLIC_API_BASE` must be a plain `http(s)://…` URL; anything else
+> is ignored and the app falls back to same-origin. If you build from source you
+> may instead bake `VITE_OMNIVOICE_API` at build time, but the runtime var above
+> is simpler and image-agnostic.
+
 > **Security:** OmniVoice ships no authentication. Anything on your LAN with
 > the URL can use the app. Put it behind a reverse proxy with `basic_auth`
 > (Caddy / nginx + htpasswd) or a private network overlay (Tailscale, ZeroTier)

docs/install/troubleshooting.md

@@ -104,9 +104,11 @@ pane shows 404s for `/media/...`.
 **Cause:** pre-v0.3, the frontend hardcoded `localhost:3900` for media-preview
 URLs, which is wrong when the UI is reached from a different LAN host.
 
-**Fix:** Plan 01-03 ships a fix that derives the media-preview base from
-`window.location.host`. See [docker.md#lan-access](docker.md#lan-access) for the
-override env var (`VITE_OMNIVOICE_API`) when running behind a reverse proxy.
+**Fix:** the frontend derives its API/media base from the page's own origin.
+When running behind a reverse proxy where the UI and API are on different
+origins, set the runtime override `OMNIVOICE_PUBLIC_API_BASE` (works on the
+prebuilt image via `docker run -e`) — see
+[docker.md#lan-access](docker.md#lan-access).
 
 ## 9. Apple Silicon `mlx-whisper` unavailable on Intel mac