docs(agent): file #125 ISO still named nixos, #126 display res invert

Bernardo: live/install ISO artifact is nixos-live-….iso (image.baseName);
live VM Display picker appeared to invert higher/lower modes — investigate
sort/apply vs QEMU scaling before fixing.

agent/BACKLOG.md

@@ -31,6 +31,62 @@ post-boot sessions). Preserve separation: the installer bake failure and the
 flake pin are different root causes even when they show up on the same machine.
 (Terminal / Ghostty-on-Acer → shipped as Kitty-only, #95.)
 
+### 125. Live/install ISO artifact is still named `nixos-…`
+
+**Observed:** a built live image lands as e.g.
+`result/iso/nixos-live-26.05.20260710.8f0500b-x86_64-linux.iso` — users (and
+USB writers) still see **NixOS**, not Nomarchy.
+
+**Already branded elsewhere:** `isoImage.volumeID = "NOMARCHY_LIVE"`,
+`isoImage.edition = "live"`, splash/GRUB theme, `system.nixos.distroName` /
+`distroId = "nomarchy"` (os-release). The **filename** comes from
+`image.baseName` / `image.fileName` (nixpkgs ISO module; formerly
+`isoImage.isoBaseName` / `isoName`), which still default to the NixOS
+template prefix.
+
+**Fix direction:** set `image.baseName` (or the current nixpkgs equivalent)
+to something like `nomarchy-live` in `hosts/live.nix` (and any install ISO
+target if split later). Confirm boot menu strings / isolinux labels if they
+still say NixOS after the rename. Guard: a cheap check or docs note that
+`result/iso/nomarchy-*.iso` is the expected path (TESTING / README build
+snippet).
+
+**Pass:** `nix build …isoImage` produces a `nomarchy-…` ISO filename (not
+`nixos-…`); volume label and user-facing boot branding stay Nomarchy.
+
+### 126. Display resolution picker: choosing higher modes makes the image smaller (live VM)
+
+**Observed (Bernardo, live ISO in a VM):** System › Display resolution
+picker — the **higher** the listed mode he picked, the **lower** the
+on-screen resolution *appeared* (inverted / wrong mapping). Live session,
+not necessarily install.
+
+**Code path:** `modules/home/rofi.nix` `display)` — builds a mode list from
+Hyprland tokens + `hyprctl monitors -j` → `.availableModes[]`, then
+`sort -rV -u`, applies with
+`hyprctl keyword monitor "$name,$mode,$pos,$scale"` and persists
+`settings.monitors.$name`.
+
+**Likely causes to separate:**
+1. **Menu/sort bug** — labels or `sort -rV` on `WxH@R` strings don’t match
+   what Hyprland applies (wrong mode string applied).
+2. **QEMU/viewer scaling** — guest mode really increases while the host
+   window is fixed, so content *looks* smaller (not a Nomarchy bug; document).
+3. **Scale factor interaction** — keeping current `.scale` while changing
+   mode on virtio-gpu yields surprising logical size.
+
+**Fix direction:** reproduce in QEMU with `tools/test-live-iso.sh` (or
+manual), log `hyprctl monitors -j` before/after each pick, assert applied
+`width`/`height` match the chosen token. Fix sort/format if wrong; if pure
+viewer scaling, tell the user and optionally show current mode from
+`hyprctl` after apply. Prefer a permanent guard on mode-string formatting
+if the bug is in our list/apply path.
+
+**Pass:** picking `1920x1080@…` yields a monitor at 1920×1080 (hyprctl);
+picking a lower mode yields lower; menu order is highest-first and honest.
+If the only inversion is QEMU window chrome, document it in TESTING.md and
+close with that finding — do not “fix” real hardware that was fine.
+
 ### 123. Installer HM pre-activate aborts on dconf / missing XDG_RUNTIME_DIR
 
 **Seen on both machines** (Dell XPS 9350 and Acer M5-481T), same log shape at