fix(waybar): gate enable on toggles.waybar (Nix-level, not session-local)

features/desktop/waybar/default.nix previously set
`programs.waybar.{enable,systemd.enable} = lib.mkDefault true`
unconditionally. The toggle script wrote .waybar to state.json and
pkill/exec'd waybar for instant feedback, but the next rebuild
re-enabled it because the Nix module didn't read the toggle. Result:
the bar came back on every rebuild/reboot regardless of the persisted
state — inconsistent with toggles.idle (gates services.hypridle.enable)
and now toggles.nightlight (gates services.hyprsunset.enable).

programs.waybar.{enable,systemd.enable} now follow
config.nomarchy.toggles.waybar. nomarchy-toggle-waybar flips the
running systemd user unit (`systemctl --user start/stop waybar.service`)
for instant feedback and writes .waybar back to state.json so the next
rebuild realigns. Disabled toggle now means no waybar across rebuilds
+ reboots, matching the option's documented meaning ("Whether the top
bar is enabled").

`nix flake check --no-build` + `bash -n` clean.

docs/ROADMAP.md

@@ -41,7 +41,6 @@ Guardrails (apply when adding anything):
 - **Decide what to do about `features/apps/chromium/Default/Preferences`.** The module deploys a static 204-byte `Default/Preferences` (setting `extensions.theme.use_system = false`, `browser.theme.color_scheme = 2`) into chromium's mutable profile directory via Home Manager symlink. Chromium expects to write that file at runtime, so either the symlink is silently replaced on first save (losing the static defaults) or the write fails silently. The real chromium theming work happens via managed policies in `core/system/browser.nix`. Probably the user-profile deployment should be removed; needs someone with chromium-internals knowledge to confirm before deletion.
 - **`nomarchy-menu` "Setup → Config" pattern edits Nix-managed files.** Five of the nine entries in `show_setup_config_menu` open files that Home Manager generates from declarative options (`hypridle.conf` from `services.hypridle.settings`, `hyprsunset.conf` from `services.hyprsunset`, `walker/config.toml` from `programs.walker.config`, `waybar/config.jsonc` from `programs.waybar.settings`, `hyprland.conf` from `wayland.windowManager.hyprland.settings`). The menu pattern is "edit then restart", but a `home-manager switch` clobbers the edit and the file goes back to the Nix-generated content. Two more entries (`hyprlock.conf`, `swayosd/config.toml`) point at paths the modules don't deploy at all — `open_in_editor` creates an empty file. Either remove these entries (the user should edit the Nix module), or rewire each to open the matching Nomarchy option doc / module file path, or document the ephemerality in `notify-send` when entering edit mode. Picked up during Pillar 8 / Component 8.
 - **`themes/templates/*.tpl` — prune the truly dead, document the rest.** Eleven mustache-style templates deployed to `~/.local/share/nomarchy/templates/` via `themes/engine/files.nix`. Originally flagged as "no script consumes them" — that was wrong: `themes/engine/scripts/nomarchy-theme-set-templates` (called at the end of `nomarchy-theme-set`) reads them, substitutes palette colors, and writes the output to `~/.config/nomarchy/current/theme/<file>` only when no file is already there. Now categorise: **(a) functionally dead** — `alacritty.toml.tpl`, `btop.theme.tpl`, `chromium.theme.tpl`, `swayosd.css.tpl` all produce files at paths nothing reads (alacritty + swayosd are Stylix/Nix-themed; btop reads from `~/.config/btop/themes/nomarchy.theme` not from the theme symlink; chromium.theme references were deleted in `9b06b6c`). **(b) superseded** — `kitty.conf.tpl` and `ghostty.conf.tpl` are now generated by `themes/engine/files.nix` (commit `8d3ce2d`); the template path skips harmlessly via the "if not exists" check. **(c) still relevant** — `hyprland.conf.tpl`, `hyprlock.conf.tpl`, `obsidian.css.tpl`, `keyboard.rgb.tpl`, `hyprland-preview-share-picker.css.tpl` (this last one was orphaned when the share-picker dir was deleted in `20de3d4` — verify before keeping). Delete (a) + (b) + the orphan share-picker tpl; document the rest in `docs/creating-themes.md` as the layered override surface they actually are.
-- **Make `nomarchy.toggles.waybar` a Nix-level gate, or document it as runtime-only.** Today the toggle is exported as `NOMARCHY_TOGGLE_WAYBAR` env, consumed only by `nomarchy-toggle-waybar` (which pkill/exec's at runtime). The Nix module always sets `programs.waybar.enable = lib.mkDefault true`, so waybar comes back on every rebuild/reboot regardless of the toggle. Inconsistent with `toggles.idle`, which correctly gates `services.hypridle.enable`. Either gate `programs.waybar.enable` on the toggle (persistent) or rename the option to make its session-only nature obvious.
 - **Package missing VSCode theme extensions via `extensionFromVscodeMarketplace`.** 15 of the 21 palettes that ship a `themes/palettes/<theme>/apps/vscode.json` declare a theme extension that isn't in `pkgs.vscode-extensions` — including `sainnhe.everforest` which is the default `summer-night` palette's theme. With the `577b3ae` fix in place, the 6 nixpkgs-packaged extensions install by default (catppuccin, catppuccin-latte, nord, tokyo-night, rose-pine, gruvbox), but the other 15 (`sainnhe.everforest`, `qufiwefefwoyn.kanagawa`, `monokai.theme-monokai-pro-vscode`, `oldjobobo.{lumon,miasma,retro-82}-theme`, `Bjarne.{ethereal,hackerman,vantablack,white}-nomarchy`, `shadesOfBuntu.flexoki-light`, `jovejonovski.ocean-green`, `TahaYVR.matteblack`) still leave `workbench.colorTheme` referencing an unloaded theme, so VSCode silently falls back. Fix: extend `features/apps/vscode.nix` to look up the active palette's extension via `pkgs.vscode-utils.extensionFromVscodeMarketplace { publisher; name; version; sha256; }` — each entry pinned by hash. Could be table-driven in `lib/` so a new palette only needs to add a row.
 
 ## 3. Pillar: Script & menu audit
@@ -153,6 +152,7 @@ Pillar is **done** when every component has a closed `wave/qa-<component>` PR an
 
 (Move items here when they land — keep them brief, link the commit/PR.)
 
+- _2026-05-22_ — **`toggles.waybar` is now a Nix-level gate.** `features/desktop/waybar/default.nix` previously set `programs.waybar.{enable,systemd.enable} = lib.mkDefault true` unconditionally, so the bar came back on every rebuild/reboot regardless of `nomarchy.toggles.waybar`. The toggle script consumed `NOMARCHY_TOGGLE_WAYBAR` but only via runtime pkill/exec — purely session-local. Same shape as the just-fixed nightlight: both options now drive their `programs.X.enable` / `services.X.enable` symmetrically with `toggles.idle` → `services.hypridle.enable`. `programs.waybar.{enable,systemd.enable}` now follow `config.nomarchy.toggles.waybar`; the toggle script flips the running unit via `systemctl --user start/stop waybar.service` for instant feedback and writes `.waybar` back to `state.json` so the next rebuild realigns. `nix flake check --no-build` + `bash -n` clean.
 - _2026-05-22_ — **Nightlight reconciled: hyprsunset gated on the toggle.** Path (b) from the Later row. `features/desktop/nightlight.nix` previously set `services.hyprsunset.enable = lib.mkDefault true` unconditionally and baked the temperature (4000K or a neutralising 6500K) into `extraArgs` at Nix-eval time, while the toggle script `pkill`'d the daemon on disable and `hyprctl dispatch exec hyprsunset --temperature 4000`'d a new one on enable — racing the systemd unit and hardcoding 4000K regardless of `nomarchy.nightlightTemperature`. Now: `services.hyprsunset.enable = lib.mkDefault config.nomarchy.toggles.nightlight` (symmetric with `services.hypridle.enable` ← `toggles.idle`), `extraArgs` always uses the option value, and the toggle script flips the running unit via `systemctl --user start/stop hyprsunset.service`, reads `nightlightTemperature` from `state.json` for the notification, and writes `.nightlight` back to `state.json` so the next rebuild realigns. Dropped the misleading "Always enabled, we control via IPC and state" comment. `nix flake check --no-build` + `bash -n` clean.
 - _2026-05-22_ — **Installer keymap reaches Hyprland's Wayland session.** `core/home/config/nomarchy/default/hypr/input.conf` hardcoded `kb_layout = us`, so the installer's `services.xserver.xkb.layout` / `console.keyMap` writes only reached XWayland and the TTY — native-Wayland apps fell back to US. Option-route fix (path (a) from the Later row): added `nomarchy.keymap.{layout,variant}` to `core/home/options.nix` (defaults `"us"` / `""`); deleted the static `input.conf` from the bulk `nomarchy/` deploy; moved it into `core/home/configs.nix` as an explicit `xdg.configFile."nomarchy/default/hypr/input.conf".text = ''…''` that interpolates the option values. Installer's `home.nix` heredoc now writes `nomarchy.keymap = { layout = "$KEYMAP_LAYOUT"; variant = "$KEYMAP_VARIANT"; };` alongside `nomarchy.formFactor`, so a non-US install propagates the layout consistently to Hyprland, XWayland, and the TTY. Documented in `docs/OPTIONS.md`. `nix flake check --no-build` clean.
 - _2026-05-22_ — **`flake.nix` palette imports consolidated through `nomarchyLib`.** `flake.nix` was re-importing `./themes/palettes` and recomputing `themeNames` via `builtins.attrNames` even though `lib/default.nix` already exports both. Two evaluations of the same data set with the same result today — drift risk tomorrow. Added `nomarchyLib = import ./lib { inherit lib; }` once in the outputs `let` and reused it via `inherit (nomarchyLib) themeNames;` for the `allThemeVariants` linkFarm. `lib/default.nix` is now the single source of truth for the theme list — modules that need palette data import `../../lib` the same way and resolve to the same evaluation. `nix flake check --no-build` clean.