shell theme: add glass-workbench as a second compiled-in theme

Phase 5 of the shell theme system (THEME_SYSTEM_PLAN.md §11): a second
builtin, demo 02's flush edge-to-edge bar with pill workspaces, a plain
date+time clock, and cpu/ram chips instead of the media widget.

- bread-theme/assets/shell/glass-workbench/: theme.toml + CSS template,
  faithful to bos-ui-demos/02-glass-workbench.html. Accent maps to the
  `green` palette token (flat, not a gradient) rather than a hex literal,
  so pywal theming still works.
- builtin.rs: generalized from a single hardcoded liquid-motion constant
  pair to a small BuiltinTheme registry (builtin::ALL / builtin::find),
  so mod.rs's discovery/list()/resolve_builtin no longer special-case one
  id. liquid-motion stays the pinned fallback in resolve_builtin().
- manifest.rs: KNOWN_MODULES gains "cpu"/"ram".
- types.rs: new Tokens::bar_border() ("full" default vs "bottom") so a
  flush bar can ask for a single hairline instead of an island's full
  border.
- Tests: builtin loads, appears in list() alongside liquid-motion, and its
  window spec is the flush/edge shape (36px, zero margin, radius 0).

cargo test -p bread-theme --lib: 63 passing (59 prior + 4 new).

bread-theme/src/shell/builtin.rs

@@ -1,23 +1,77 @@
-//! The one compiled-in theme (plan §11 phase 1: "**One** built-in manifest
-//! (`liquid-motion`) describing the bar as it exists today"). Both files are
-//! plain data, not Rust — `theme.toml` is the manifest text a user override
-//! would otherwise supply, and `liquid-motion.css` is the CSS template
-//! `ShellTheme::css` substitutes tokens into (see that method's doc comment
-//! for why this template is a representative subset of `breadbar::theme::
-//! load_css`'s full stylesheet rather than a byte-for-byte copy of it).
+//! The compiled-in themes (plan §11 phase 1/5: "**One** built-in manifest
+//! (`liquid-motion`) describing the bar as it exists today", extended in
+//! Phase 5 with `glass-workbench`, demo 02). Every file here is plain data,
+//! not Rust — each `theme.toml` is the manifest text a user override would
+//! otherwise supply, and each `<id>.css` is the CSS template `ShellTheme::css`
+//! substitutes tokens into (see that method's doc comment for why this
+//! template is a representative subset of `breadbar::theme::load_css`'s
+//! full stylesheet rather than a byte-for-byte copy of it).
 //!
-//! Both are read with `include_str!` so a broken build can't ship without
-//! them, and so [`super::builtin`] never touches the filesystem — it must
-//! work identically whether or not `$XDG_CONFIG_HOME` exists at all.
+//! All are read with `include_str!` so a broken build can't ship without
+//! them, and so [`super`] never touches the filesystem for a builtin — it
+//! must work identically whether or not `$XDG_CONFIG_HOME` exists at all.
 
 pub const LIQUID_MOTION_ID: &str = "liquid-motion";
 
-pub const LIQUID_MOTION_TOML: &str = include_str!(concat!(
+const LIQUID_MOTION_TOML: &str = include_str!(concat!(
     env!("CARGO_MANIFEST_DIR"),
     "/assets/shell/liquid-motion/theme.toml"
 ));
 
-pub const LIQUID_MOTION_CSS: &str = include_str!(concat!(
+const LIQUID_MOTION_CSS: &str = include_str!(concat!(
     env!("CARGO_MANIFEST_DIR"),
     "/assets/shell/liquid-motion/liquid-motion.css"
 ));
+
+pub const GLASS_WORKBENCH_ID: &str = "glass-workbench";
+
+const GLASS_WORKBENCH_TOML: &str = include_str!(concat!(
+    env!("CARGO_MANIFEST_DIR"),
+    "/assets/shell/glass-workbench/theme.toml"
+));
+
+const GLASS_WORKBENCH_CSS: &str = include_str!(concat!(
+    env!("CARGO_MANIFEST_DIR"),
+    "/assets/shell/glass-workbench/glass-workbench.css"
+));
+
+/// One compiled-in theme's identity plus its two `include_str!`ed assets.
+/// `id`/`name` are also duplicated inside `toml`'s own `id =`/`name =`
+/// fields — kept here too so [`all`]/[`find`] can list/look up a builtin
+/// without parsing TOML first (`super::list`'s builtin fallback entry, and
+/// `super::find_source`'s existence check, both run before any manifest
+/// parsing happens).
+pub struct BuiltinTheme {
+    pub id: &'static str,
+    pub name: &'static str,
+    pub toml: &'static str,
+    pub css: &'static str,
+}
+
+/// Every compiled-in theme, in the order [`super::list`] should present
+/// them. Adding a third builtin is one entry here plus its two asset files
+/// — nothing else in `mod.rs` names a specific builtin id except the always-
+/// -safe fallback ([`LIQUID_MOTION_ID`], deliberately still hardcoded at
+/// its one call site in `super::resolve_builtin` — see that function's doc
+/// comment for why that one reference must NOT become "whichever builtin is
+/// listed first").
+pub const ALL: &[BuiltinTheme] = &[
+    BuiltinTheme {
+        id: LIQUID_MOTION_ID,
+        name: "Liquid Motion",
+        toml: LIQUID_MOTION_TOML,
+        css: LIQUID_MOTION_CSS,
+    },
+    BuiltinTheme {
+        id: GLASS_WORKBENCH_ID,
+        name: "Glass Workbench",
+        toml: GLASS_WORKBENCH_TOML,
+        css: GLASS_WORKBENCH_CSS,
+    },
+];
+
+/// Looks up a compiled-in theme by id — `None` means "not a builtin",
+/// exactly like a miss in the user/system theme directories.
+pub fn find(id: &str) -> Option<&'static BuiltinTheme> {
+    ALL.iter().find(|t| t.id == id)
+}