Summary

Display the web client's version — the version field from clients/web/package.json — in the lower-right corner of the web UI, in grey (subdued/dimmed) text. This matches what the CLI and TUI already show and gives web users an at-a-glance build identifier.

Background

The CLI and TUI both surface their version by reading their own package.json at runtime:

• CLI — clients/cli/src/cli.ts reads ../package.json for the client identity (name/version).
• TUI — clients/tui/src/App.tsx reads package.json and renders v{packageJson.version} in its header.

The web client shows no version today. There is no shared core/ helper that reads a version — each client does its own ad-hoc read — so we either add a small shared reader or (simpler) have the web backend read it and hand the value to the browser.

Suggested approach (backend reads, passes to client)

The browser can't read the filesystem, so the natural path is to have the Node backend read clients/web/package.json (as CLI/TUI do) and pass the version through the existing initial-config channel:

1. Add version?: string to InitialConfigPayload (core/mcp/remote/node/server.ts) — the shape returned by GET /api/config.
2. Populate it in the backend. webServerConfigToInitialPayload() in clients/web/server/web-server-config.ts builds that payload; have it (or its caller in server.ts / vite-hono-plugin.ts) read the web package.json version and set it. Reading it there keeps the fs access on the Node side, mirroring the CLI/TUI reads.
   • Optional cleanup: factor the "read a client's package.json version" logic into a tiny shared helper (e.g. under core/) that CLI, TUI, and the web backend all use, instead of three separate reads. Nice-to-have, not required.
3. Consume it in the browser. The app already reads GET /api/config (see useServerListWritable / useSandboxUrl). Expose version the same way and render it.

UI

• Position: fixed lower-right corner of the screen.
• Style: grey / dimmed, small — unobtrusive. Use an --inspector-* text token (e.g. a muted/secondary text color), not a raw hex/rgba literal, per the Mantine styling rules in AGENTS.md. Prefer a Mantine Text with theme props over a CSS class.
• Content: e.g. v2.0.0 (or v{version}).
• Must not overlap/obscure interactive controls; should sit above content but out of the way.

Acceptance

• The web UI shows the clients/web/package.json version in the lower-right corner, in grey.
• The value is sourced from the real package.json version (not hard-coded), surfaced via the backend → GET /api/config → browser path (or an agreed equivalent).
• Styling uses Mantine props + --inspector-* tokens (no raw color literals, no inline styles).
• Tests cover the new payload field and the rendered version (unit/Storybook as appropriate), keeping the per-file ≥90% coverage gate.