feat(live): the live ISO gets a desktop — browser, office, editor — for +41 MiB

BACKLOG #103. Bernardo, live ISO 2026-07-14: still no browser, no office —
"that makes a live iso useful". He is right, and it is the thing a user judges
the distro by before installing, and what they boot to rescue a machine that
won't start. It could do neither.

The live HM user now names its own set: chromium, libreoffice-fresh,
gnome-text-editor, amberol, snapshot. Firefox deliberately excluded (Bernardo's
call): chromium already owns the HTTP mime default and ships in the installed
template, so it is the browser that matches what a user gets post-install.

I asked him to choose on a "~+2 GB" premise. The premise was wrong, and
measuring rather than assuming is what corrected it: system.extraDependencies
ALREADY pins the template's HM closure into the ISO for offline installs, so
chromium/libreoffice/amberol were already in the image's store — merely absent
from the live user's profile, so nothing put them on PATH or in the launcher.
The live and template chromium resolve to the SAME store path, verified, so
reusing the template's exact `chromium.override { enableWideVine = true; }`
costs zero; a plain `chromium` would have been a second 2.5 GiB closure. Only
gnome-text-editor and snapshot are new: 9 paths, 133 MiB uncompressed. His
Firefox call still held for the right reason — it was the one item genuinely
unpinned.

V2. Measured ISO delta, both built from the same tree — the item's pass
condition: 8.038 → 8.078 GiB = +41.2 MiB (+0.50%). New
checks.live-baseline-apps asserts each app is on PATH *and* has a .desktop the
launcher can see (a binary without one is invisible, which is the failure that
matters), that HTTPS resolves to a chromium entry actually PRESENT (#94's exact
trap — a mime default naming a package nothing ships), and that firefox has not
crept back, since that is a size decision not a drive-by. The guard was proved
to fail: dropping snapshot makes it name the missing entry. flake check,
live-install-entry, option-docs, template-sot green.

V3 pending: that the apps LAUNCH needs hardware — queued on the Acer M5-481T,
from the launcher only, since that is the claim a file-level check cannot make.

Also filed, from measuring the 8 GiB rather than speculating about it:
  * #120 (NEXT, Bernardo's call) — a netinstall ISO beside the offline one.
    Starts from numbers: the offline pin is only 4.02 of 18.03 GiB uncompressed
    (~22%), so dropping it still leaves a 14 GiB desktop (~6.3 GiB compressed).
    "No pin" is not the lighter ISO; and without a binary cache for Nomarchy's
    own outputs a netinstall trades a download for a from-source install.
  * #121 — the Widevine wrapper drags a SECOND 687 MiB unwrapped chromium in
    for its share/applications alone. Pre-existing, on every installed machine.
  * #119 — text/plain names vscode, which the live ISO never ships.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/ROADMAP.md

@@ -367,10 +367,43 @@ Design/decision records and a running log of shipped work (items marked
   just reinholds what a package list already gives, and the honest opt-out for
   a package is *deleting the line*. So the suite is the user's own curated list
   (extending the existing `# firefox` convention), not a distro-module feature —
-  which also keeps the apps out of the live ISO automatically (it never starts
-  from the template) and respects that editor/office/graphics are personal-taste
-  choices, not defaults to impose. Unfree `vscode` evaluates fine — `mkFlake`
-  and the system both set `allowUnfree = true`.
+  and it respects that editor/office/graphics are personal-taste choices, not
+  defaults to impose. Unfree `vscode` evaluates fine — `mkFlake` and the system
+  both set `allowUnfree = true`. **Amended 2026-07-14 (#103):** this design
+  also kept the apps off the live ISO automatically (it never starts from the
+  template) — which was read as a feature here, and was in fact the bug: the
+  live session had no browser and no office at all. The live medium now names
+  its own baseline set explicitly (see below); "the template is the app list"
+  still holds for *installed* machines.
+- ✓ **Live-ISO baseline apps (#103):** the live session shipped the distro
+  modules only — no browser, no office — for as long as it existed. That is
+  the thing a user judges the distro by *before* installing, and what they
+  boot to rescue a machine that will not start; it could do neither. The live
+  HM user in `flake.nix` now names its own set: **Chromium, libreoffice-fresh,
+  gnome-text-editor, amberol, snapshot** (Bernardo confirmed the gap on real
+  hardware 2026-07-14).
+  **Firefox deliberately excluded** (Bernardo's call): Chromium already owns
+  the HTTP mime default and ships in the installed template, so it is the
+  browser that matches what a user gets after installing — and it was the one
+  item on #103's original list that would have cost a real closure.
+  **The size finding, which inverted the trade:** `system.extraDependencies`
+  already pins the template's HM closure into the ISO for offline installs, so
+  chromium/libreoffice/amberol were *already in the image's store* — merely
+  absent from the live user's profile, so nothing put them on PATH or in the
+  launcher. Reusing the template's **exact** derivations (including
+  `chromium.override { enableWideVine = true; }` — a plain `chromium` would be
+  a second full browser build) makes those three cost **zero**. Only
+  gnome-text-editor and snapshot are new: 9 store paths, 133 MiB uncompressed
+  (99 MiB of it gst-plugins-rs, Snapshot's media stack). **Measured ISO delta:
+  8.038 → 8.078 GiB = +41.2 MiB (+0.50%)**, both built from the same tree.
+  Guard: `checks.live-baseline-apps` asserts each app is on PATH *and* has a
+  `.desktop` the launcher can see (a binary without one is invisible, which is
+  the failure that matters), that HTTPS resolves to a chromium entry which is
+  actually **present** — #94's exact trap, a mime default naming a package
+  nothing ships — and that Firefox has not reappeared, since that is a size
+  decision rather than a drive-by. Proved to fail: dropping snapshot makes it
+  name the missing entry. **V3 pending** — that the apps *launch* needs real
+  hardware (HARDWARE-QUEUE, Acer M5-481T).
 - ✓ **Plymouth logo contrast:** the shipped art was a fixed navy that
   vanished on dark bases. `modules/nixos/plymouth.nix` now recolors every
   element from the palette at build time (flat fill, alpha kept):