fix(client): serve /index.css from the frontend instead of the backend

[mrramam]

Fixes #174.

Plugin iframes have never received the real theme stylesheet in a container
deployment. The backend serves /index.css by reading client/src/index.css off
disk, trying four candidate paths; server/Dockerfile builds with server/ as
its Docker context, so the image contains server/ and nothing else and none of
those paths can resolve. It works natively from a full checkout, which is how it
went unnoticed.

The request did not fail after the four ENOENTs the handler served a hardcoded
substitute, so plugins got a valid 200 with the wrong content, under different
variable names (--text-color, --error-color where the real sheet has
--text, --error) and an inverted theme model.

Changes

Serve it from the frontend. Vite emits an unhashed index.css at the site
root from src/index.css, and nginx serves that file instead of proxying. It is
emitted rather than copied into public/, so there is one source and no second
file to drift.

Drop the substitute. A stylesheet that silently supplies different values
under different names is worse than none: plugins carry their own
var(--x, default) fallbacks and those only work if this path stays quiet. It
now 404s.

The backend handler stays, deliberately. A plugin iframe loads from
API_BASE_URL, so its root-relative /index.css resolves against the backend
origin whenever that differs from the page's which is exactly npm run dev.
There the file is present and served correctly. In containers API_BASE_URL is
empty, the iframe is same-origin, and the request reaches nginx.

Depends on jherforth/HomeGlowPlugins#13

This changes which variable names plugins receive, and the two stylesheets are
not subset and superset. chore-metrics.html uses var(--text-color, #333) — a
name only the substitute defined so merging this alone leaves it rendering dark
grey text on the dark --card-bg.

Landing the plugin PR first is safe; landing this one first leaves that
plugin unreadable in the interval. All 24 plugins were checked and
chore-metrics is the only one using a retired name.

Verified

On a container deployment, with the check that discriminates: front
GET /index.css returns the real 5174-byte sheet, and the backend origin
returns 404. A 200 on the front door alone was true of the broken build too,
since the substitute answered it.

Known limit

Plugins now get the real palette but still the defaults, not a customized
theme. The app overrides roughly fifteen of these variables at runtime from user
settings, and interfaceColors lives only in localStorage, so no server-side
render can be correct. Matching the live theme would need the host to inject
computed values into the iframes a separate, larger change.

[jherforth]

Reviewed critically and merging. The dependency is in place and I verified each structural claim rather than taking it on trust.

The diagnosis is correct, and provable from the build config

docker-image.yml builds the backend with context: ./server, and server/Dockerfile does COPY . .. So client/src/index.css cannot exist in that image under any of the four candidate paths — the failure is structural, not a path bug. And it works natively from a checkout, which is exactly why it went unnoticed.

The substitute is also the source of a confusion I ran into separately: it defined --text-color and --error-color, names the real sheet does not have, with an inverted theme model. That is why chore-metrics was written against var(--text-color, #333) and rendered dark grey on the dark --card-bg.

The ordering constraint is satisfied

HomeGlowPlugins#13 is merged, and chore-metrics.html on that repo's main now has zero --text-color references and uses var(--text. Safe to land this.

What I verified

The emitted stylesheet is real, not a copy that can drift. Built the client on this branch:

dist/index.css        5404 bytes, unhashed, at the dist root
identical to src/index.css:  yes
defines --text:              yes        defines --text-color:  no
hashed sheets still emitted: index-CCHwdNXJ.css, layout-Cb7KG80W.css

client/Dockerfile does COPY --from=builder /app/dist /usr/share/nginx/html, which is precisely where root + try_files $uri resolves it. And location = /index.css is an exact match, so it wins over the static-asset regex — nginx resolves exact matches before regex, so that comment is right.

Same-origin in containers holds. getApiUrl() returns '' outside development, and nginx proxies /api/, /uploads/, /widgets/ and /plugin-sdk/ to the backend. A plugin iframe at /widgets/x.html is therefore same-origin with the page and its /index.css reaches nginx, not the backend.

The dev path is not regressed — this was the one I most wanted to check, since breaking it would hit every developer. Backend on this branch:

GET /index.css -> 200 text/css
identical to src/index.css:  true
defines --text: true | --text-color: false | --error-color: false

Server 225/225, client 281/281, translation parity, CI green on both jobs.

One consequence worth stating plainly

For a split-origin deployment — VITE_REACT_APP_API_URL pointed at a different origin — the iframe stays cross-origin, the request lands on the backend, and plugins now get no stylesheet where they previously got the wrong one. That is the right trade and your reasoning for it is sound: plugins carry var(--x, default) fallbacks, and those only work when this path is quiet. Worth being explicit that it is a real behaviour change for that non-default configuration, not only for containers.

Also agreed on the known limit. Plugins getting the real palette but the default values is a genuine improvement over the wrong palette, and injecting the computed theme into iframes is rightly a separate change.

Small thing: the body says "the real 5174-byte sheet" — it measures 5404 now. The number is just stale, the check behind it is the right one.