Keep the Work items and Projects selection on the saved item after a reorder #91

Description

In Manage > Work items and Manage > Projects, the list selection is a row index (selected: usize). A save that changes the list order does not move that index. After Back, the highlight sits on whatever item now holds the old position, and Enter opens that item, not the one just saved.

Verified at ba301aed:

• Work items: a priority or rank save reloads the list from its first page (work_items.rs:468, L493). The reload only clamps the index (L284). Back scrolls to that index (L409), and Enter opens it (L631).
• Projects: a saved project goes through upsert, which re-sorts the rows by priority and then slug (projects.rs:45-52). selected is an index into the visible rows and is not updated (L346, L794).

Saves are not affected. Each editor writes to its own item's path (editor.item.path(), projects::path(&slug)), and both probes recorded exactly one write, to the edited item.

Reproduced twice with headless #[gpui_kit::test] probes in a scratch copy of ba301aed. The probes reuse the existing in-memory FakeWork and FakeProjects. For Work items, the fake lists in priority-then-rank order, so a priority save actually moves the row (the stock FakeWork lists in insertion order). Results were the same on both runs:

PROBE work change=work-priority-0 order_after=[202, 200, 201] selected_ix=2 enter_opened=#201 writes=1   (expected #202)
PROBE work change=work-status-blocked order_after=[200, 201, 202] selected_ix=2 enter_opened=#202 writes=1   (control: order unchanged)
PROBE projects act=["project-priority-0", "project-save"] visible_after=["gh-x", "project-dashboard", "set-it-free-loop", "hs-buddy", "chief"] enter_opened=hs-buddy writes=1   (expected gh-x)
PROBE projects act=["goal=Probe goal", "project-save"] visible_after=["project-dashboard", "set-it-free-loop", "hs-buddy", "gh-x", "chief"] enter_opened=gh-x writes=1   (control: order unchanged)

Steps in the UI: open Manage > Work items, open the third row, pick P0, Save, Back, press Enter. The editor opens a different item. Projects: open gh-x (fourth row), pick P0, Save, Back, Enter: hs-buddy opens.

Not covered here: the Manage > Fleet dialog uses the same index pattern (selected: [usize; 3] in manage/fleet.rs), but it was not probed.

Why

Arrows and Enter are the documented keyboard flow for both dialogs (#34, #35). After a reorder, the highlighted row and the Enter target silently become a different item, so the user loses their place, and anyone who doesn't reread the editor title can start editing the wrong item. Re-prioritizing several items in a row is exactly when this happens.

Goal

After a save, a reload or a re-sort, the list selection stays on the same item, matched by identity (work item id, project slug) rather than by position. When that item has left the list, the selection lands on a valid row.

Acceptance Criteria

• Work items: after a priority or rank save that moves the item, Back highlights that item at its new position, scrolls it into view, and Enter reopens it.
• Projects: after a priority save that moves the project, Back highlights that project at its new position and Enter reopens it.
• A save that does not change the order keeps the current behavior: the same item stays selected.
• When the saved item is no longer listed (for example, a status save under a status filter, or Untrack while untracked rows are hidden), the selection is on an existing row and Enter opens that row's item, never nothing.
• Filter changes still reset the selection to the first row, as they do now.

Definition of Done

• The fix is in dashboard-app/src/manage/work_items.rs and manage/projects.rs. Any identity-matching logic that can be tested without a window goes in dashboard-core, per AGENTS.md.
• Headless UI tests in work_items_tests.rs and projects_tests.rs cover the reorder case and the item-left-the-list case. The Work items fake lists in a priority-then-rank order, so a reorder actually happens in the test.
• The new tests fail on ba301aed and pass with the fix.
• cargo fmt --all --check, cargo clippy --workspace --all-targets --locked -- -D warnings, cargo test --workspace --locked and cargo deny --locked check advisories pass; all required CI checks are green.
• The PR closes this issue with Closes #n.

Validation

• cargo test -p dashboard-app --locked -- work_items_tests projects_tests passes, including the new reorder tests. Check out the new tests on ba301aed, unchanged, and confirm that they fail there.
• Manual or headless steps from the Description: Work items row 3 → P0 → Save → Back → Enter opens the saved item; Projects gh-x → P0 → Save → Back → Enter opens gh-x.
• The PR embeds current-head screenshots, uploaded as GitHub attachments and rendered from the headless capture test (CAPTURE_DIR=$PWD/captures cargo test -p dashboard-app captures -- --ignored on Linux or macOS). They show, at the default window size and in the default theme: the Work items list after Back from a reordering save, with the saved item highlighted at its new position, and the same for the Projects list.
• A recording of the keyboard flow is added if practical; otherwise the PR says why not.

No current-state screenshots are attached here. This diagnosis was limited to headless tests: running the GUI was out of scope, and the capture test runs only on Linux or macOS, while the probe ran on Windows.