Grid SortZone incorrectly intercepts column resize drag events, causing VDOM corruption and layout thrash

Description

When resizing a grid column (using grid.header.plugin.Resizable), the draggable.grid.header.toolbar.SortZone was concurrently intercepting the same drag:start, drag:move, and drag:end events because both plugins listen to the same header button DOM nodes.

This caused the SortZone to execute its column-reordering logic during a resize operation. Specifically, SortZone.onDragStart would falsely identify a column as being dragged and set its columnPosition.hidden = true and cell.style.visibility = 'hidden'. This led to grid cells vanishing during resize. Furthermore, SortZone.onDragEnd would needlessly trigger grid.body.createViewData(false, true), causing massive performance degradation by forcing a full, un-recycled VDOM regeneration of the entire grid body on every resize.

Solution

1. Mutex via Config: Repurposed the dragResortable config on the header toolbar as a runtime semaphore.
2. Resizable Plugin: Modified grid.header.plugin.Resizable to set toolbar.dragResortable = false on drag:start and restore it to true on drag:end. Also optimized the toolbar lookup from owner.up() to owner.parent.
3. SortZone Bailouts: Added strict if (!me.owner.dragResortable) return; bailouts to the very top of onDragStart, onDragMove, and onDragEnd in draggable.grid.header.toolbar.SortZone. This cleanly severs the event processing if a resize is active.
4. Cleanup: Removed the now-obsolete delete cell.style.visibility; "self-healing" hack from grid.Body#updateCellPositions since the underlying VDOM corruption is prevented entirely.