docs(agent): file #143 (rofi keeps the row number) and #144 (migration: profiles.ini)

#143 — Bernardo: type `ca`, move onto ChatGPT, backspace once, and the
highlight sits on GHex while Slack is row 1. Upstream rofi 2.0.0, not our
config: listview_set_num_elements() re-asserts the OLD index —
`listview_set_selected(lv, lv->selected)` — and set_selected only clamps
(`MIN(selected, req_elements - 1)`). So the ROW NUMBER survives a
refilter, never the entry, and nothing checks it still matches the query.
Typing more hides it; backspacing exposes it. No option controls it
(auto-select is a different feature). Correction to the report: it is the
listview widget, so every rofi surface does it — drun is just where the
list is long and (sort = true) reorders each keystroke.

#144 — "I lost all my thunderbird accounts and emails" was a missing
profiles.ini. The profile was untouched: 30 GB, 64 account prefs, 19 GB
ImapMail, last used 2026-06-26; TB found no profile list and made an
empty one. Fixed live in ~8 lines (backup kept). MIGRATION.md already
warns about this exact class for Chromium extensions but never names
Mozilla's profiles.ini — which deserves its own bullet because it is the
inverse: no data lost, looks catastrophic, and the tempting fix (restore
a snapshot over a good 30 GB profile) is the actual risk. Firefox here
has the same fingerprint (hm-bak from Jun 2025 names a different profile
than today's ini) — left alone; repointing it is Bernardo's call.

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

agent/BACKLOG.md

@@ -198,6 +198,100 @@ scaled splash — the LUKS prompt especially, since a passphrase box half off
 the panel is the failure that matters. Pass = docked boot + shutdown centred
 on both heads; undocked unchanged.
 
+### 144. MIGRATION.md must warn about Mozilla `profiles.ini` — it reads as total data loss
+
+Bernardo 2026-07-16: "it seems that I have lost all my thunderbird accounts and
+emails!" — nothing was lost. `~/.thunderbird/bernardo` was intact the whole
+time: **30 GB**, 64 account/identity prefs, 19 GB `ImapMail` + 9.7 GB `Mail`,
+last used 2026-06-26. Only `profiles.ini` was gone, so on first launch after the
+migration Thunderbird did what it always does with no profile list — created an
+empty one (`wc966grk.default`, 16 MB) and pointed itself at it. Fixed by
+rewriting `profiles.ini` to `Path=bernardo` + `Default=1` (old file kept as
+`profiles.ini.bak-*`); Thunderbird reopened the real profile and went straight
+into its Duo login. **Total fix: one 8-line file.**
+
+This is the **same class** MIGRATION.md's "Browser profiles" bullet already
+covers — a file Home Manager used to manage disappears, and the app reads its
+own absence as "first run" — but that bullet only names Chromium extensions.
+The Mozilla case deserves its own warning precisely because it is *louder and
+less dangerous*: Chromium silently deletes extension data (real loss, looks
+minor); Thunderbird touches nothing and merely looks away from 30 GB (no loss,
+looks catastrophic). A user who believes the second one will go restore a
+snapshot over a perfectly good profile — the recovery is the risk here.
+
+Firefox on this box shows the same fingerprint, unreported because he browses in
+Chromium: `~/.mozilla/firefox/profiles.ini` (Jul 12) points at
+`u9p8fdhh.default` (101 MB, created at migration), while
+`profiles.ini.hm-bak` — Home Manager's own backup, dated **Jun 2025** — points
+at `lfr4aapb.default` (129 MB, last used 2025-09-07), and a third profile
+`default` (290 MB) was last used 2026-03-02. So the pattern is Mozilla-family,
+not Thunderbird-specific. **Do not repoint Firefox without asking Bernardo** —
+u9p8fdhh has been in use since Jul 14 and merging profiles is his call.
+
+**What to write** (docs only, no code): in MIGRATION.md's Phase-0/browser
+section — before first launch of any Mozilla app, check that
+`~/.thunderbird/profiles.ini` and `~/.mozilla/firefox/profiles.ini` exist and
+name your real profile directory; if an app opens empty, **do not restore a
+snapshot** — `ls ~/.thunderbird` first, and if a fat profile dir is sitting
+there, it is a one-file fix. Include the working `profiles.ini` shape and the
+`Name=`/`Path=`/`Default=1` semantics.
+
+**Root cause is unproven and probably not worth chasing:** zero HM generations
+survive on disk to show whether HM ever managed that file (the Firefox
+`.hm-bak` proves it did there, in 2025), and the snapshot check needs sudo. The
+warning is worth writing either way — it costs nothing and it is the difference
+between a one-line fix and a restore that overwrites good data.
+
+### 143. Rofi keeps the selected *row number* when the search changes, so the highlight lands on an unrelated entry
+
+Bernardo 2026-07-16, and his repro is exact: open the app menu, type `ca`, move
+the selection two items right (onto ChatGPT), press backspace once (query is
+now `c`). The list re-expands — first entry is now Slack — but the highlight
+stays on the **third row**, which is now GHex, an app that has nothing to do
+with what he typed. Enter at that moment launches the wrong thing.
+
+**Cause — upstream rofi (2.0.0, `source/widgets/listview.c`), not our config.**
+A filter change ends in `listview_set_num_elements()`, which does not reset the
+selection; it re-asserts the old one:
+
+```c
+lv->req_elements = rows;
+listview_set_selected(lv, lv->selected);   /* the *previous* index */
+```
+
+and `listview_set_selected()` only clamps it to the new bounds:
+
+```c
+lv->selected = MIN(selected, lv->req_elements - 1);
+```
+
+So what is preserved is the **row number**, not the entry — nothing checks that
+row 2 still holds the thing that was selected, or that it matches the query at
+all. Typing *more* hides this (the list shrinks, the clamp usually drags the
+highlight along); **backspacing exposes it**, because the list grows back
+underneath a stationary index. There is no option for it: `-dump-config` has
+nothing about selection-on-refilter, and `auto-select` is a different feature
+(it fires only when exactly one row survives).
+
+**One correction to the report:** it is not the app menu. `listview` is the
+widget behind **every** rofi surface we ship, so our text menus (Recovery,
+System, Preferences…) do the same. It is merely far more visible in drun, where
+the list is long and — because we set `sort = true` — reorders on every
+keystroke, so a stationary index points somewhere new each time. In a short
+text menu you would probably see it and correct without noticing why.
+
+**Options.** (a) Report upstream and wait — this is a widget-level bug, and the
+fix belongs there: reset to row 0 in `rofi_view_refilter_real` when the filter
+text actually changed (the "keep the index" behaviour is presumably wanted for
+non-filter reloads, so it cannot simply be deleted). (b) Carry the patch
+ourselves in an overlay — a few lines, but it means **building rofi from source
+on every user's machine**: our derivations are in no binary cache (#120's
+gotcha), so this trades a real install/rebuild cost for it. (c) Live with it
+and say nothing — the status quo, and the reason Bernardo hit it cold.
+Recommend (a) + (b) together if the patch stays small: file it upstream, carry
+it until it lands, delete on the release that fixes it. `[human]` for whether
+a source-built rofi is a price worth paying.
+
 ### 142. A rebuild while docked undoes dock mode (the panel comes back, a workspace jumps to it)
 
 Bernardo 2026-07-16: every rebuild while docked lands in the undocked state —