fix: load workspaces through remote HTTP proxies

[mariusvniekerk]

Opening kenn-forge through a plain-HTTP reverse proxy could leave the Workspaces view blank. The sidebar required a browser API that is unavailable on insecure origins. Vite also told remote browsers to connect hot module replacement to their own loopback address.

Use Svelte's component identity for workspace refresh ownership, and let Vite derive its development WebSocket endpoint from the page origin. Explicit HMR overrides remain available for proxies that expose a different host, protocol, or port. The full-stack insecure-origin regression opts in only inside the isolated Docker E2E job, so ordinary local runs never bind its non-loopback proxy.

Validation

• Frontend unit suite: 3,887 passed, 2 skipped.
• Local workspace-sidebar Playwright suite: 24 passed, 8 skipped across Chromium and Firefox.
• Frontend checks, non-mutating lint, commit hooks, push hooks, and public-safety scans passed.

^{generated by a clanker}

[roborev-ci]

roborev: Combined Review (8a26968)

The PR has one high-severity security issue and one medium-severity test coverage gap.

High

• Network-exposed test proxy enables arbitrary command execution — frontend/tests/e2e-full/00-workspace-sidebar.spec.ts:216

  The unrestricted reverse proxy binds to a non-loopback interface and forwards all requests to the loopback-only e2e server, which has the host runtime enabled. A network-adjacent attacker could invoke POST /api/v1/runtime/sessions with attacker-controlled commands and working directories, executing code as the CI runner or developer account.

  Bind the proxy only to loopback and map a test hostname to 127.0.0.1 using Chromium host-resolver rules. Alternatively, allow only the required read-only routes and reject mutation/runtime endpoints.

Medium

• HMR behavior lacks end-to-end regression coverage — frontend/src/lib/dev/viteConfig.test.ts:38

  The test only asserts the generated configuration object; it does not verify that a page accessed through an alternate origin connects to /__vite_hmr on that origin and receives updates.

  Add an integration/e2e test using an alternate-origin, WebSocket-capable proxy and verify that an HMR update reaches the browser.

---

Reviewers: 2 done | Synthesis: codex, 14s | Total: 4m6s

[roborev-ci]

roborev: Combined Review (e04ded9)

The changes look sound, but the remote-origin Vite HMR behavior lacks end-to-end coverage.

Medium

• frontend/vite.config.ts:75 — The HMR fix is covered only by a configuration-object assertion. The Playwright test uses the embedded production SPA, so it never starts Vite or exercises the HMR WebSocket. Page-origin routing could regress undetected. Add a gated browser integration test that runs Vite behind a non-loopback reverse proxy and verifies /__vite_hmr connects through the page origin, ideally by observing a hot update.

---

Reviewers: 2 done | Synthesis: codex, 13s | Total: 5m10s