refactor(flake): consolidate palette imports through nomarchyLib

flake.nix was re-importing ./themes/palettes and recomputing
themeNames via builtins.attrNames in its outputs `let`, even though
lib/default.nix already exports both. Two evaluations of the same
data, same result today — drift risk tomorrow as soon as one
computation grows extra logic the other doesn't.

Added `nomarchyLib = import ./lib { inherit lib; }` once and reused
it via `inherit (nomarchyLib) themeNames;` for the allThemeVariants
linkFarm. The local `palettes` binding wasn't read by anything else in
the outputs so it goes away with the rewrite. lib/default.nix is now
the single source of truth for the theme list; modules under core/
and themes/engine/ already import ../../lib the same way and resolve
to the identical evaluation.

`nix flake check --no-build` clean.

flake.nix

@@ -38,6 +38,12 @@
     system = "x86_64-linux";
     lib = nixpkgs.lib;
 
+    # Shared Nomarchy helpers (palette loader, theme name list, wallpaper /
+    # icon-theme resolvers, base16 mapper). Importing here makes lib/default.nix
+    # the single source of truth — modules that need palette data import
+    # `../../lib` the same way and resolve to the same evaluation.
+    nomarchyLib = import ./lib { inherit lib; };
+
     # Overlays — the function form lives here so both Nomarchy itself and
     # any downstream flake (see `overlays.default` in the outputs) can layer
     # the same Nomarchy packages onto their nixpkgs.
@@ -76,8 +82,7 @@
     # pins `nomarchy.theme` (and clears the wallpaper override so the theme's
     # own default background is used) and exposes the generation's activation
     # package under its theme name.
-    palettes = import ./themes/palettes;
-    themeNames = builtins.attrNames palettes;
+    inherit (nomarchyLib) themeNames;
     themeVariantFor = themeName: (mkHome {
       username = "nomarchy";
       modules = [{