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>

agent/JOURNAL.md

@@ -19,6 +19,48 @@ Template:
 
 ---
 
+## 2026-07-14 — #103: the live ISO gets a desktop, for +41 MiB (this commit)
+- **Task:** BACKLOG #103 — Bernardo, live ISO 2026-07-14: still no browser,
+  no office. *"That makes a live iso useful."*
+- **Did:** the live HM user in `flake.nix` now names its own set — chromium,
+  libreoffice-fresh, gnome-text-editor, amberol, snapshot. Firefox dropped
+  (Bernardo's call): chromium owns the HTTP mime default and ships in the
+  installed template, and it was the one item that would cost a real closure.
+- **The finding that inverted the trade:** I asked Bernardo to choose on a
+  ~+2 GB premise. Wrong premise — `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**, just absent from
+  the live user's profile. Verified, not assumed: the live and template
+  chromium resolve to the *same store path*, 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 text-editor and
+  snapshot are new: 9 paths, 133 MiB uncompressed (99 MiB is gst-plugins-rs).
+  His Firefox call still held for the right reason — it was genuinely unpinned.
+- **Verified:** **V2** — measured ISO delta (the item's pass condition), both
+  built from the same tree: **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 bin without one is invisible), that HTTPS
+  resolves to a chromium entry that is actually **present** (#94's trap), and
+  that Firefox has not crept back. **Proved to fail:** dropping snapshot makes
+  it name the missing entry. flake check + live-install-entry + option-docs +
+  template-sot green.
+- **Pending:** **V3** — that the apps *launch* needs hardware (HARDWARE-QUEUE,
+  Acer M5-481T: from the launcher only, no terminal). New **#119**: `text/plain`
+  names vscode, which the live ISO never ships — #94's bug one mime key over,
+  and now the last of its kind.
+- **Where the 8 GiB actually goes** (Bernardo asked how Debian fits one in 4 GB;
+  I first blamed the offline-install pin and **that was wrong** — measured, the
+  pin is 4.02 of 18.03 GiB uncompressed, ~22%). The live *desktop itself* is
+  **14.01 GiB**: libreoffice 1457 MiB, initrd 1369, linux-firmware 770, mesa,
+  fonts, two chromiums (see #121). Debian fits ~4 GB by installing *by copying
+  the live filesystem* (no second closure) and by sharing one library version
+  archive-wide, where Nix pins exact deps per package. Compression is not the
+  gap — we already use `zstd -19` (2.23:1). Bernardo's call: **keep the offline
+  ISO as is**, add a netinstall variant → **#120** (NEXT). Filed **#121**: the
+  Widevine chromium wrapper drags a *second* 687 MiB unwrapped chromium in for
+  its `share/applications` alone — pre-existing, on every installed machine.
+- **Next suggestion:** #118 (smartd self-gate) — Bernardo's stated order.
+
 ## 2026-07-14 — triage: #117 is not work, it's an input to #110 (this commit)
 - **Task:** Bernardo's call on #117 (filed by the previous entry, which
   suggested it as the next item — it is not; that suggestion is stale).