Refusing to start the drag while a move was running left nothing to read:
pressing a row just did nothing, with no signal about why.
A drag that can't be dropped now behaves like any other drag — it starts,
follows the pointer, and carries the whole selection. What changes is the
feedback: no drop target highlights, rows and columns show a not-allowed
cursor, the drag preview carries a short reason, and releasing lands in
moveItems, which says what to do about it.
Both blocking reasons run through the same path, so the over-cap case
gets this treatment too instead of only the running-move case:
getDropBlockedReason -> 'Move in progress' | 'Max 25 items' | undefined
It's computed once in the provider and read from the dnd context, so rows,
columns, and the preview can't disagree about whether a drop is possible.
The bulk Move button and its shortcut stay disabled with a tooltip. A
disabled control with an explanation is already legible, and it's the
pattern Studio uses elsewhere — it was only the silent drag that wasn't.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016Q9CRWzLS6pPuLmfPmn5uT
Claude
8e335582fb