diagram: component-library CSS modules hardcode light colors with no dark-mode overrides

[bpowers]

Problem

The component library CSS modules under src/diagram/components/*.module.css hardcode light-theme colors (#fff backgrounds, rgba(0, 0, 0, ...) text/borders) with no [data-theme="dark"] variants, while src/diagram/theme.css defines a full set of dark-mode design tokens and some feature-level CSS (Editor, ModuleDetails) already ships dark rules.

Verified state:

• 16 component modules hardcode #fff / rgba(0,0,0,...): Accordion, AppBar, Autocomplete, Button, Card, Checkbox, Dialog, Drawer, IconButton, InputAdornment, Menu, Paper, Snackbar, SpeedDial, Tabs, TextField.
• Zero of the components/*.module.css files contain a data-theme*dark selector (no dark overrides).
• src/diagram/theme.css defines dark-mode tokens ([data-theme="dark"] block present).

Why it matters

Latent today because the editor chrome isn't dark-themed in the shipping app. But any future dark-theming effort (the root CLAUDE.md lists dark mode as supported via [data-theme="dark"]) will leave menus, dialogs, drawers, text fields, autocompletes, buttons, and cards rendering as bright white boxes against a dark surface -- an inconsistent, broken-looking UI. The infrastructure (tokens) already exists; the library modules just don't consume it.

Component(s) affected

src/diagram/components/ -- the 16 *.module.css files listed above.

Possible approach

Migrate the library modules off hardcoded literals onto the theme.css custom properties (CSS variables), which already carry correct light/dark values. This is a mechanical sweep: replace #fff / rgba(0,0,0,...) with the corresponding var(--...) token. No per-component dark rules needed once the tokens are used, since theme.css already redefines them under [data-theme="dark"].

How discovered

Identified during UI/theming review of the diagram component library.