Build gate: fail vite build on a browser-externalized Node built-in (SEP of #1615)

[cliffhall]

Motivation

Follow-up from #1615 / PR #1768. While adding the headless-browser boot smoke, we measured what the pinned vite@8.0.0 actually does when a Node built-in reaches the browser graph:

• A node:* (or bare builtin via a dep's browser field) import is externalized at build time with a warning (plugin rolldown:vite-resolve: Module "node:fs" has been externalized for browser compatibility), and the build still succeeds, shipping a silent module.exports = {} stub.
• CI does not fail on that warning, so nothing upstream of the runtime gates it.

Consequences:

• CASE 1 (the stub is called at module init): crashes the app at runtime → caught by smoke:web:browser (CI: add a headless-browser boot smoke for the web client #1615). That smoke is currently the only gate for this shape.
• CASE 2 (the stub is imported but never called): ships a harmless {} and is invisible to the browser smoke by design — nothing catches it.

Proposal

Make vite build treat that specific browser-externalization warning as an error (e.g. via an onwarn/onLog hook in clients/web/vite.config.ts, or Rolldown's warning-to-error mechanism). That would:

• move CASE 1 detection upstream of the smoke into npm run build / validate (a Node built-in in the browser graph fails the build instead of shipping a broken bundle), and
• additionally catch CASE 2, which the runtime smoke cannot see.

The browser smoke stays valuable as the runtime backstop (it catches crashes the build can't reason about), but the build gate is the cheaper, earlier, more complete catch for the externalization class specifically.

Notes

• Verify the exact warning code/shape emitted by the pinned Vite (it differs across 8.0.x → 8.1.x — 8.1.5 reportedly fails the build outright, 8.0.0 warns), and key the gate off something stable.
• Keep it scoped to browser-target builds; the Node runner build legitimately uses built-ins.

Discovered during the review of PR #1768.