Fix multi-selected desktop icons only ever dragging one at a time

Reported live: "try move desktop items all at once somewhere else"
didn't work. Two compounding bugs, both real: CompState::
desktop_icon_drag only ever tracked one icon id, and the click handler
that starts a drag unconditionally collapsed any existing multi-
selection down to just the grabbed icon before the drag even began.

desktop_icon_drag is now Option<DesktopIconDrag> (crates/wayland/src/
desktop_icons.rs, new type): a grab offset, the grabbed icon's own live
position, and a members list - every currently-selected icon (the
grabbed one included), each a fixed offset from the grabbed icon's own
top-left at drag start, so the group moves as one rigid unit.
input/pointer.rs's click handler now only resets to single-selection
when the grabbed icon isn't already part of the current selection --
grabbing one inside an existing multi-selection keeps the whole group
selected and dragging, matching Windows/GNOME/macOS/KDE convention.
end_desktop_icon_drag snaps every dragged icon to its own nearest free
grid cell independently, tracking newly-claimed cells across the group
so two icons landing near each other never claim the same one.

Full workspace build/test/clippy clean, built and installed. Not unit-
testable (this module has no CompState test fixture for its own
selection/drag logic, an already-documented, accepted gap) - needs a
live drag to confirm.

1 files changed, 8 insertions, 0 deletions

diff --git a/docs/TODO.md b/docs/TODO.md
index 98deb48..e539ffb 100644
--- a/docs/TODO.md
+++ b/docs/TODO.md
@@ -13,6 +13,14 @@ that has the full story. Keep this list current as items close or open;
 update the source doc's own entry too, don't let this drift into a
 second stale copy the way `PANEL_SUPPORT_TODO.md` did.
 
+## Real bug, root-caused and fixed: dragging a multi-selected desktop icon only ever moved that one icon (2026-08-27)
+
+Reported live: "try move desktop items all at once somewhere else" didn't work. Confirmed by reading the actual data, not guessed: `CompState::desktop_icon_drag` only ever held one icon id, and - the real, compounding bug - the click handler that starts a drag (`input/pointer.rs`) called `select_desktop_icon(Some(&id))` *unconditionally* before starting the drag, which collapses any existing multi-selection down to just the one icon being grabbed. Even if the drag itself had supported multiple icons, that call site would have destroyed the selection before it ever got the chance.
+
+Fixed both halves. `desktop_icon_drag` is now `Option<DesktopIconDrag>` (`crates/wayland/src/desktop_icons.rs`, new type): a grab offset, the grabbed icon's own live position, and a `members` list - every currently-selected icon (the grabbed one included), each recorded as a fixed offset from the grabbed icon's own top-left at drag start, so the whole group moves as one rigid unit. `input/pointer.rs`'s click handler now only resets to single-selection when the grabbed icon *isn't* already part of the current selection - grabbing an icon inside an existing multi-selection keeps the whole group selected and dragging, the same "drag one of several selected files, they all move" convention Windows/GNOME/macOS/KDE all share. `end_desktop_icon_drag` snaps every dragged icon to its own nearest free grid cell independently, tracking newly-claimed cells across the group so two dragged icons landing near each other never both claim the same one.
+
+Full workspace build/test/clippy clean (223 core / 141 wayland / 29 platform / 24 ctl / 28 config / 10 x11 tests). Not unit-testable the way the placement fix above was - this module has no `CompState` test fixture for its own selection/drag logic (already documented as a real, accepted gap in this same file's own "rubber-band desktop icon selection" entry, not new to this fix) - needs a live drag to confirm, same as that entry's own outstanding item.
+
 ## Real bug, root-caused and fixed: every new window opened alone landed in the exact same spot, not at all like Windows (2026-08-27)
 
 Reported live. Root-caused by reading `SmartPlacement::place`, not guessed: it tried a grid cell first, falling back to cascade only once the grid was full. Grid's own cell count is `existing.len() + 1` - with nothing else open (the overwhelmingly common real workflow: open one app, use it, close it, open the next), that count is always `1`, so the grid is always exactly one cell, and a 1x1 grid returns the same single cell every time regardless of session history. Cascade had a second, compounding version of the same bug: its own step was `existing.len() % max_steps`, also always `0` with nothing else open, so even a from-scratch cascade calculation reset to the origin on every call.