docs(roadmap): ship Gaming flathub remote

Moved the entry from Next → Shipped following commit 2948dc4
("feat(gaming): register Flathub remote via one-shot systemd unit").

docs/ROADMAP.md

@@ -24,7 +24,6 @@ Guardrails (apply when adding anything):
 ### Next (bigger lifts that build on Now)
 
 - **Accessibility — home-side companion.** Hyprland-side bits the system preset can't reach: slower `input.repeat_rate` / `repeat_delay` defaults, `SUPER+ALT+S` keybinding to launch Orca, and a high-contrast palette under `themes/palettes/`. Gated on a new `nomarchy.accessibility.enable` mirror of the system option.
-- **Gaming — declarative flathub remote.** `services.flatpak.enable` doesn't ship a declarative remote API in nixpkgs. Either add the `flatpak-managed-install` overlay, write a one-shot systemd unit that runs `flatpak remote-add --if-not-exists flathub …`, or surface the manual step in `nomarchy-welcome`.
 - **Plymouth theme variants per palette.** Currently one Plymouth theme; could template per-palette so the boot splash matches the active theme.
 - **Implement `nomarchy.overrides.*` file-based override loader.** The option surface is declared in `core/home/overrides.nix` but the loader doesn't exist — files dropped under `~/.config/nomarchy/overrides/` are ignored. Spec: when `overrides.enable = true`, for each `xdg.configFile.<path>` Nomarchy deploys with `lib.mkDefault`, check whether `~/.config/nomarchy/overrides/<path>` exists at build time; if so, use it as the source. Requires deciding whether discovery happens at activation time (cheap, but rebuild-required to pick up new files) or via a populated `paths` attrset (Nix-side, evaluated once per rebuild). Until shipped, document the per-file workaround (`xdg.configFile.<path>.source = ./mine`) in OPTIONS.md.
 
@@ -151,6 +150,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_ — **Gaming preset: flathub remote registered automatically.** `services.flatpak.enable = true` (set inside `core/system/gaming.nix`'s `mkIf cfg.enable` block) shipped flatpak but didn't add any remotes — `flatpak install` and the Discover GUI returned empty results until the user ran the manual `flatpak remote-add` one-liner. nixpkgs has no declarative remote-add API. Added `systemd.services.nomarchy-flathub-init`: a `Type=oneshot`, `RemainAfterExit=true` unit that runs `flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo` after `network-online.target`. The `--if-not-exists` flag keeps it idempotent across reboots and re-runs. Lives under the gaming preset (where flatpak is wired today); lift to a dedicated module when another preset needs flatpak. Closes the "Gaming — declarative flathub remote" Next-column item.
 - _2026-05-22_ — **`nomarchy-menu` "Setup → Config" submenu removed.** Of the nine entries, five (`hyprland.conf`, `hypridle.conf`, `hyprsunset.conf`, `walker/config.toml`, `waybar/config.jsonc`) opened Home-Manager-generated files that get clobbered on the next `home-manager switch`; two (`hyprlock.conf`, `swayosd/config.toml`) pointed at paths the modules don't deploy at all; `XCompose` was a HM-managed symlink to the Nix store (read-only). The "edit + restart" pattern was an Omarchy holdover that didn't translate to Nomarchy's declarative-first model. Removed `show_setup_config_menu` entirely and dropped the "  Config" item from `show_setup_menu` (closes the case branch in the parent menu). Persistent settings now go through the matching `nomarchy.*` option in `/etc/nixos/home.nix` (or `system.nix`); when the `nomarchy.overrides.*` loader ships, the menu can come back routed through `~/.config/nomarchy/overrides/`. Side effect: `nomarchy-restart-xcompose` now `unused?` in `docs/SCRIPTS.md` (regenerated) — left as a future Pillar 3 cleanup, not widened into this 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.