local-dev: Vite proxy for same-origin requests + upstream gateway Dockerfile fix

vite.config.ts now proxies `/api` and `/galaxy.gateway.v1.EdgeGateway`
to the gateway, so the browser sees only `localhost:5173` and never
trips a cross-origin preflight. `.env.development` accordingly points
`VITE_GATEWAY_BASE_URL` at the Vite origin. The proxy target is
overridable via `VITE_DEV_PROXY_TARGET=...` for non-default gateways
without touching the compose file.

`gateway/Dockerfile` previously failed to build because gateway
imports `galaxy/core` (replaced to `../ui/core` in `gateway/go.mod`)
but the Dockerfile did not copy `ui/core/` into the build context
nor declare the replace in the synthesised `go.work`. Adding both
makes `docker build -f gateway/Dockerfile .` succeed; this is the
same fix already shipped in `tools/local-dev/gateway.Dockerfile`,
back-ported to upstream.

Verified:
- docker build -f gateway/Dockerfile . — builds cleanly
- pnpm test 14/14, pnpm exec playwright test 44/44 (with CI=1 to
  force a fresh dev server; reuse keeps the previous startup env)
- curl POST through localhost:5173/api/* and /galaxy.gateway.v1.* —
  reach the gateway, no CORS preflight on the browser side

tools/local-dev/README.md updated with the new network map and the
`VITE_DEV_PROXY_TARGET` override.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

ui/frontend/vite.config.ts

@@ -10,9 +10,36 @@ const pkg = JSON.parse(
 	),
 ) as { version: string };
 
+// Default upstream gateway address used by the dev proxy. Override by
+// pointing `VITE_DEV_PROXY_TARGET` at a different gateway when working
+// with a remote stack instead of `tools/local-dev/`.
+const DEV_PROXY_TARGET =
+	process.env.VITE_DEV_PROXY_TARGET ?? "http://localhost:8080";
+
 export default defineConfig({
 	plugins: [sveltekit()],
 	define: {
 		__APP_VERSION__: JSON.stringify(pkg.version),
 	},
+	server: {
+		// Same-origin proxy so the browser sees only `localhost:5173`
+		// and never trips a cross-origin preflight against the
+		// gateway's REST + Connect-Web surfaces. Production deployments
+		// serve the UI and the gateway behind a single host, so the
+		// proxy is purely a dev-time convenience.
+		proxy: {
+			"/api": {
+				target: DEV_PROXY_TARGET,
+				changeOrigin: false,
+			},
+			"/galaxy.gateway.v1.EdgeGateway": {
+				target: DEV_PROXY_TARGET,
+				changeOrigin: false,
+				// Connect-Web server-streaming (`SubscribeEvents`) uses
+				// chunked HTTP responses; http-proxy passes them through
+				// transparently as long as buffering stays off, which is
+				// the default.
+			},
+		},
+	},
 });