fix(dev): make Vite dev server reachable from LAN browsers

[ajslater]

Summary

Three coupled issues prevented browsing the dev server from a second
Mac on the LAN (with the host advertised via mDNS as e.g. hooloovoo.local).
None reproduce on the host itself, which made the symptoms misleading.

bin/dev-server.sh

Dropped export VITE_HOST=localhost. The line overrode the auto-derivation
in codex/settings/__init__.py:_vite_dev_server_host(), so django-vite
rendered <script src="http://localhost:5173/..."> regardless of mDNS,
and any browser that wasn't on the host Mac tried to load the bundle
from its own loopback.

frontend/vite.config.js

• server.cors.origin — Vite 6+ defaults server.cors.origin to a
  regex that only matches localhost / 127.0.0.1 / [::1]. Browsers
  hitting Django at http://<host>:9810 and then fetching from
  http://<host>:5173 got Vary: Origin back but no
  Access-Control-Allow-Origin, so the scripts were blocked. Mirror
  allowedHosts into a port-agnostic CORS regex.
• server.hmr.host — With server.host: true and no explicit
  hmr.host, Vite bakes localhost into the HMR client's
  directSocketHost and socketHost strings. Remote browsers opened
  the HMR WebSocket against their own loopback (ERR_CONNECTION_REFUSED).
  Set hmr.host to the same VITE_HOST / mDNS-mangled hostname Django
  uses for <script src> so the embedded URL agrees with where the page
  actually loaded the module from.
• allowedHosts — Include the resolved HMR_HOST so an explicit
  VITE_HOST=... override (one that doesn't match os.hostname()) is
  also trusted by Vite's host-header check and the new CORS regex.

Vite still hardcodes localhost into one more string — the diagnostic
serverHost variable in @vite/client — but that's only used inside a
console error message template when HMR fails, never for an actual fetch.
Influencing it would require pinning server.host to a single name,
which loses loopback access from the host machine.

Test plan

• On the host machine: ./bin/dev-server.sh and bun run dev (in
  frontend/) start cleanly; browsing http://<host>.local:9810/
  loads the app with HMR working.
• On a second Mac on the LAN: browsing the same URL loads the app,
  script tags resolve, HMR WebSocket connects.
• curl -s http://<host>.local:5173/static/@vite/client | grep -E 'serverHost|directSocketHost'
  shows directSocketHost = <host>.local:5173/... (only serverHost
  should still be localhost, which is cosmetic per above).
• curl -sI -H "Origin: http://<host>.local:9810" http://<host>.local:5173/static/@vite/client
  returns an Access-Control-Allow-Origin header.
• Localhost workflow on the host (http://localhost:9810/) still
  works.

🤖 Generated with Claude Code