[Gratenes]

Web client

Summary

This adds an opt-in browser client for zeron: the engine's remote listener serves an embedded web app over HTTP + WebSocket, with every bearer verified as a WorkOS AuthKit access token — the same checks the edge applies to relay clients.

Remote access stays off by default. Local IPC, the edge, iOS, and sync are untouched.

How it works

Engine side

• serve_engine_remote binds an HTTP+WebSocket listener exposing the same RPC surface as IPC. Every request's bearer is verified by remote_auth::RemoteAuthorizer: WorkOS access-token JWTs against the WorkOS JWKS (with caching + rotation refetch), or the dev bearer (userId / userId@orgId) when no WorkOS client id is configured. The same verifier protects the WebSocket data plane (first-frame Auth).
• Pre-auth routes: GET /auth/config reports the sign-in mode and the AuthKit authorize URL; POST /auth/exchange proxies the secret-bearing code exchange to the edge, so the WorkOS API key only ever lives engine↔edge, never in the browser.
• The web bundle is embedded with rust-embed: build.rs stages the Vite build into web-staging/ (placeholder pages in debug, ZERON_WEB_DIST override). The HTML shell loads before the credential gate; the data plane stays gated.
• Opt-in via remote-access.json / the ZERON_NETWORK startup override.
• web_conformance / web_smoke examples run the real listener in dev-auth mode for the test suites.

Web side (web/ — a pnpm workspace, @zeron/{app,engine-client,proto,theme,icons})

• @zeron/engine-client: the RPC client (reconnect + re-auth, generation-based watch streams), the watch cache, the fleet registry (one supervised connection per engine, merged under scoped ids), and the sign-in flow (fetchSignInConfig / exchangeSignInCode) — a dev engine takes a local user id; a WorkOS engine redirects through AuthKit and the pasted code exchanges through the engine's proxied route.
• @zeron/app: the full web app — chat transcript, composer, fleet sidebar, settings, dialogs, command palette, mobile layouts — adapted to the sign-in model: /pair is the connect page, the Devices settings links into it, and the pairing-code surface (methods, proto types, remote-access settings page) is removed.
• Browser-side engine registry persists per-origin in localStorage; damaged persisted config is preserved and blocks sign-in until repaired (the desktop registry's refusal semantics).

Commits

• feat(engine): WorkOS-authenticated remote engine listener — listener, remote_auth verifier, rpc WebSocket pump, off-by-default remote access
• feat(web): web client workspace + engine-served bundle — the ported web/ workspace + rust-embed staging
• feat(engine): pre-auth sign-in routes for the web client — /auth/config + proxied /auth/exchange
• feat(web): sign-in flow replaces engine pairing codes — the browser sign-in migration; pairing deleted
• ci(web): web client build, unit, and live-engine conformance jobs

Testing

• cargo test -p zeron-engine --test remote_listener — 11/11 (HTTP credential gate, first-frame envelope auth, web routes, dev bearer)
• cargo test -p zeron-rpc — 12/12; cargo test -p zeron-proto — 43/43
• pnpm -r build — typecheck + Vite build green
• engine-client: 43/43 (unit 33; conformance 5 and smoke 5 run against live engines spawned from the examples — full sign-in, watch, mutate, reconnect-with-resubscribe, cache swap semantics)
• app suite: 1873/1873
• CI: new Web client workflow runs the build, unit suites, remote_listener tests, and the live-engine conformance/smoke suites on web/**-touching PRs

Notes for reviewers

• The branch is based on current zeron main (c914b319) with no merges; every commit is a forward port.
• Nothing here changes default behavior: without remote-access.json / ZERON_NETWORK, the listener never binds and the web bundle is never served.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}