replace the monochrome theme with the CYBER neon-cyan skin

The project shipped a black-and-white theme that was only half converted:
the login page looked right, the message page was halfway, and the
settings page had not been started. This finishes the move to the CYBER
reference in prototype_reference/.

Colors now come from a single token source (styles/variables.scss), where
every semantic color is declared twice: once as OKLCH for the CSS, and
once as an RGB triple so translucent variants can be built as
rgba(var(--*-rgb), alpha). Cyan is the system itself, amber means the user
has to intervene, green means the machine is working, and red only ever
means something broke. The RGB triples are derived from the OKLCH values
so the two declarations cannot drift apart.

Pages adopt the .cy-* shell classes from the reference (view, panel,
kpis, tabs, grid, table, field) instead of ad-hoc markup, which is what
makes 19 of 26 views consistent. The remaining seven are deliberately
bespoke: chat streams, the kanban board, the workflow canvas, the
terminal, and the missing-agent screen.

The chart palette and the kanban column colors move into single-source
modules so they cannot drift either. A new guard test rejects raw hex
colors, named colors, and literal RGB triples anywhere in the client
source, with an explicit exemption list for the places that genuinely
cannot read a CSS variable. The existing chat semantics spec keeps the
chat chain honest.

No behavior changes: no logic, no i18n keys, no data structures, and the
/chat-run event contract is untouched.

DEVELOPMENT.md

@@ -7,11 +7,14 @@ This document defines project-level development rules for hermes-ui. It is tool-
 - Node.js `>=23` (see `engines` in `package.json`).
 - Python with `hermes-agent` installed. The Hermes CLI is not bundled; point
   `HERMES_BIN` at the executable or make `hermes` resolvable from `PATH`.
+- A C/C++ toolchain, **but only on Linux**: `python3`, `make`, `g++`. See
+  "Platform Notes" below.
 
 ## Commands
 
 ```bash
 npm ci --ignore-scripts
+npm rebuild node-pty
 npm run dev
 npm run test
 npm run test:coverage
@@ -20,12 +23,62 @@ npm run build
 ```
 
 - `npm ci --ignore-scripts` installs exactly what `package-lock.json` pins. Do not upgrade dependencies.
+- `npm rebuild node-pty` is **required**, not optional. `npm ci --ignore-scripts`
+  skips every install script, and `node-pty`'s install script is what puts a
+  loadable native module in place. Skipping it leaves the terminal feature
+  silently disabled — the server logs a warning and keeps running.
 - `npm run dev` starts the Vite client and Koa server together.
 - `npm run test` runs Vitest unit tests.
 - `npm run test:coverage` is what the Build workflow runs before `npm run build`.
 - `npm run test:e2e` runs Playwright browser tests against a mocked BFF API.
 - `npm run build` type-checks and builds both client and server.
 
+## Platform Notes
+
+The server runs on Windows, macOS, and Linux. The parts that differ are
+isolated behind `process.platform` checks, so the same source runs everywhere.
+
+### node-pty
+
+`node-pty` ships prebuilt binaries for Windows and macOS only:
+
+| Platform | Where the native module comes from | Build step |
+| --- | --- | --- |
+| Windows | `prebuilds/win32-<arch>/` (shipped in the npm tarball) | not needed |
+| macOS | `prebuilds/darwin-<arch>/` (shipped in the npm tarball) | not needed |
+| Linux | **none — must be compiled from source** | `npm rebuild node-pty` |
+
+On Linux, `npm rebuild node-pty` compiles `node-pty` from source and needs
+`python3`, `make`, and `g++` on the machine. The Dockerfile installs exactly
+those for this reason.
+
+On macOS the prebuilt `spawn-helper` may arrive without its executable bit.
+The server repairs that at startup
+(`packages/server/src/routes/hermes/terminal.ts`), and `bin/hermes-ui.mjs`
+does the same for the installed CLI.
+
+### Other platform differences
+
+- **Terminal shell**: `powershell.exe` on Windows, `$SHELL` (falling back to
+  `/bin/zsh` then `/bin/bash`) on macOS and Linux.
+- **Agent Bridge transport**: a Unix domain socket at
+  `ipc:///tmp/hermes-agent-bridge.sock` on macOS and Linux, a TCP port
+  (`tcp://127.0.0.1:18765`) on Windows, which has no Unix socket support in
+  Node.
+- **Python interpreter**: `python3` on macOS and Linux, `python` on Windows.
+  Virtualenv layout differs too (`venv/bin/python3` vs `venv\Scripts\python.exe`).
+- **Gateway process tree**: `taskkill /T` on Windows, process-group signals on
+  macOS and Linux.
+- **Hermes home**: `~/.hermes` on macOS and Linux; on Windows, an existing
+  `%LOCALAPPDATA%\hermes` or `%APPDATA%\hermes` takes priority.
+
+### Verification
+
+Linux is covered by the `Build` and `Playwright` workflows, which run on
+`ubuntu-latest`. macOS is not covered by any hosted runner; the
+`macOS Verification` workflow (`workflow_dispatch` only) runs the same checks
+when a macOS runner is available.
+
 ## Architecture
 
 - Frontend code lives under `packages/client/src`.