Add the component loader

The most granular level of our loading strategy is the Component Loader. Unlike global or page-level loaders, component loaders must target specific, isolated UI elements (widgets, tables, or cards). To achieve this without state collisions, we will implement a dynamic registry in the UXStore that tracks loading states using a unique composite key for every registered component.

The logic for generating unique IDs, registering states, and rendering the overlay will be encapsulated within a custom Vue directive. This ensures that any element or component can be turned into a "loading-aware" container simply by attaching a directive, while the actual state remains centrally managed in the UXStore.

1. Key Generation Strategy
The directive must automatically generate a collision-proof key to track the loading state in the global store.
- Key Format: ${el.id}:${vnode.ctx.uid}
- This combines the DOM ID (for traceability) with the Vue internal instance UID (to handle multiple instances of the same component).

2. The v-component-loading Directive
Create a directive that handles the entire lifecycle of the component loader:
- created / mounted:
- Generate the unique composite key.
- Register the key in the UXStore.componentLoaders Map with an initial state of false.
- Inject the loader HTML/Spinner into the DOM or manage a transition overlay.
- updated:
- Watch the store for changes to that specific key and toggle the "active" class/visibility of the overlay.
- beforeUnmount:
- Clean up the key from the UXStore to prevent memory leaks and a bloated state.

3. UXStore Map Integration
Update the UXStore to support this dynamic registration:
- State: componentLoaders: Map
- Action: setComponentLoading(id: string, isLoading: boolean) — This will be called by Store Actions during data fetching.

NB/
Implementing this granular, ID-based loading architecture opens the path toward a Skeleton Loading pattern. By decoupling the "loading" state from the content, we can eventually swap the generic spinner for component-specific skeleton screens without changing our business logic or store orchestration.