docs: remove HUB_STATIC_DIR claims the hub doesn't implement (CL-9612)

apps/hub/README.md

@@ -21,9 +21,9 @@ native tenant middleware.
 - There are no local `src/*-mount.ts` wiring helpers: each extension's
   routes mount directly in `src/index.ts` with the shared DB
   handle/config passed inline at the `app.route(...)` call site.
-- Serves the built `apps/web` SPA from its own origin
-  (`HUB_STATIC_DIR` points at `apps/web/dist`), so every `/api` call the
-  interface makes is same-origin.
+- Serves no static files. In dev, `vite dev` (apps/web) serves the SPA and
+  proxies `/api` to the hub; in e2e, `e2e/lib/browser.ts` serves the built
+  `apps/web/dist` itself, in front of the hub, on one origin.
 - `credential-expiry-sweep.ts`, `workflow-scheduler.ts`, and
   `inbox-unsnooze-sweep.ts` are host-level periodic sweeps wired at boot,
   alongside the route mounts; `cron-due.ts` is a re-export seam onto

apps/web/README.md

@@ -2,13 +2,14 @@
 
 The workbench's single-page interface: every screen and route lives here,
 composed from the published `@corbits/react-ui` component library, and
-builds to a static bundle the hub serves from its own origin (`vite
-build`, then point `HUB_STATIC_DIR` at `apps/web/dist`). It is a Vite SPA
-over the hub's `/api` — every product rule (what a screen may show, how
-data is shaped) lives in a package; this app stays a generic composition
-of package UI and routing, per [AGENTS.md](../../AGENTS.md). In dev,
-`vite dev` proxies `/api` to a locally running hub so the interface is
-developed against real data without a build step.
+builds to a static bundle in `dist/` (`vite build`). The hub serves no
+static files. It is a Vite SPA over the hub's `/api` — every product rule
+(what a screen may show, how data is shaped) lives in a package; this app
+stays a generic composition of package UI and routing, per
+[AGENTS.md](../../AGENTS.md). In dev, `vite dev` serves the SPA and proxies
+`/api` to a locally running hub, so the interface is developed against real
+data without a build step. In e2e, `e2e/lib/browser.ts` builds and serves
+`dist/` itself on the same origin as the hub.
 
 ## Layout
 

apps/web/package.json

@@ -2,7 +2,7 @@
   "name": "@workbench/web",
   "version": "0.0.1",
   "private": true,
-  "description": "Single-page interface for the workbench: every page and route lives here, composed from the published component library, and builds to a static bundle the hub serves from its own origin (point HUB_STATIC_DIR at apps/web/dist)",
+  "description": "Single-page interface for the workbench: every page and route lives here, composed from the published component library, and builds to a static bundle in dist/",
   "license": "SEE LICENSE IN ../../LICENSE.md",
   "repository": {
     "type": "git",

apps/web/vite.config.ts

@@ -1,6 +1,5 @@
-// The build lands in apps/web/dist with root-relative asset URLs; point the
-// hub's HUB_STATIC_DIR at that directory and the interface is served from the
-// hub's own origin, so every /api call is same-origin with no CORS setup.
+// The build lands in apps/web/dist with root-relative asset URLs. The hub
+// serves no static files; e2e/lib/browser.ts serves dist itself.
 //
 // `vite dev` proxies /api to a locally running hub so the interface can be
 // developed against real data without a build step.