Dark mode was persistent in `AppearanceSettings` but never reached any
paint code: every call site in the shell read `colors::INK` etc. as a
`pub const u32`, so toggling `ThemeMode::Dark` mutated state nothing
sampled. Root-cause fix is to invert the contract — the design-system
exports functions that resolve through a thread-local `Mode`, and the
GPUI render impl sets that mode each frame.
What lands:
- `ely_design_system::colors::Mode` + thread-local + `set_mode` /
`mode` accessors. Every ink shade, glass surface, stroke, divider,
hairline, canvas, success / error chip now picks the warm-dark
counterpart when the active mode is `Mode::Dark`.
- `ElyShell::render` resolves `ThemeMode::System` against
`Window::appearance()` and pushes the mode before traversing the
tree, so widgets lower down read the right shade without owning a
`Mode` parameter.
- `render_wallpaper` + `panel_bg` now branch on `colors::mode()` so
the gradient base, panel tint, and overlay highlights flip to
warm-graphite when dark mode is active.
- Mechanical conversion across 687 call sites in 55 files from
`colors::FOO` constants to `colors::foo()` accessors. The
`Theme` / `ELY_THEME` const surface (unused outside the design
system) is removed; the function surface is the new contract.
Plugin detail now opens with the design's marketplace card: a
4/3 brand-gradient cover plus install/secondary buttons plus a
permissions list with risk badges on the left, and a category
overline plus serif Newsreader title plus description plus a
4-up real-data stat grid (permissions, high-risk, contributes,
signature) plus a "What it adds to ELY" contributions list on
the right. Every value comes from PluginManifest — no fabricated
ratings, install counts, or feature copy.
Internal: chrome::plugin_detail_view holds the layout, and
chrome::plugin_labels owns the permission scope labels and
contribution copy so plugin_detail_view stays under 500 lines.
The internal_pages/plugin_details.rs shim only handles route
parsing and the missing-plugin fallback.