docs(agent): #143 reported upstream — rofi#2317

Filed as bemagri against davatorium/rofi with the 2.0.0 line numbers
(view.c:861 → listview.c:622-631 → :646-651) read from the exact source
nixpkgs builds, not the next branch. No duplicate: the nearest, #1064,
is the opposite request (keep the selection after EXECUTING an entry —
closed, milestone 1.7.4), which is also why the report scopes itself to
the filter-changed path and sends no patch: that behaviour is deliberate
for reloads and the scoping call is the maintainer's.

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

agent/BACKLOG.md

@@ -280,10 +280,15 @@ 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
+**Reported upstream 2026-07-16: https://github.com/davatorium/rofi/issues/2317**
+(open, filed as `bemagri`, with the 2.0.0 line numbers and the observation that
+`rofi_view_set_selected_line` already maps a stable id through `line_map` — so
+the fix reuses an existing primitive rather than inventing one). No patch was
+sent: the scoping call is the maintainer's, since keeping the index across a
+*reload* looks deliberate (#1064 asked for exactly that, and got it in 1.7.4).
+No duplicate found before filing.
+
+**Options.** (a) Wait for upstream — done, now their move. (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