[Refactor] Rename container.sortable to container.dragResortable

✦ I would rate the impact of this session as High.

Impact Analysis:

• Architectural Clarity (High):

  • Disambiguation: The most critical win is separating sortable (data sorting) from dragResortable (item reordering). This resolves a confusing naming collision that was causing friction in complex components like Grids and Tables. It makes the API self-documenting.
  • Standardization: Moving the SortZone creation logic to container.Base and establishing a clear override pattern (loadSortZoneModule, createSortZone) enforces a consistent architecture across the framework.

• Developer Experience (High):

  • Less Boilerplate: By leveraging inheritance in grid and table header toolbars, we deleted redundant imperative code. Future container extensions will be easier to write.
  • Predictability: Developers now know exactly which config controls what behavior. dragResortable is explicit.

• Maintainability (Medium-High):

  • Centralized Logic: Fixing or enhancing the drag-and-drop initialization logic now happens in one place (container.Base), rather than being scattered across multiple afterSet... methods.
  • CSS Consolidation: Merging the toolbar animation CSS into container/SortZone.scss simplifies the theme structure.

• Risk (Medium - Breaking Change):

  • This is a breaking change. Any existing application using sortable: true on a TabContainer, Dashboard, or generic Container for drag-and-drop will break until updated.
  • However, the migration path is trivial (search & replace), and the long-term benefit of avoiding the sortable conflict outweighs the short-term pain.

Summary: This was a necessary maturation step for the framework. As you added more complex components (Grid, Table), the overloaded sortable term became a technical debt liability. Paying it down now prevents future bugs and makes the learning curve smoother for new adopters. The code is cleaner, DRY-er, and more semantic.