Cohesive UX loading state management

To support our Hydrate-Before-Route pattern and improve perceived performance, we need to move away from fragmented loading logic. This issue tracks the implementation of a centralized loading orchestration system within the UXStore.

The strategy categorizes all UI states into two logical buckets: Blocking (Full App) and Non-Blocking (Contextual).

### 1. Blocking UI State (The Global Gatekeeper)

The Global Application Loader is the only state that prevents user interaction. It serves as a "front" for the application while mandatory domain data is hydrated.

The app will default to this loader being shown and will get cleared after the following actions are completed:
- Auth Check & User Retrieval: Initial verification of the
- Platform Settings: Fetching core configuration required for the UI shell.
- RBAC (Permissions/Roles): Loading the security context before the router resolves.
- Team Retrieval: Identifying and setting the active team context.

Similar to the existing platform pending loader state

### 2. Non-Blocking UI States (Contextual Loaders)

To increase perceived loading speeds, secondary data fetching should occur behind non-blocking overlays that allow the application shell to remain visible/active.

- Page Loader: Overlays the ff-page component during route transitions or while primary page entities are being fetched.

- Modal/Drawer Loader: Specific to overlays. This covers the content area of a modal or drawer while its internal data dependencies resolve.

- Component Loader: The most granular level. Overlays individual widgets or UI sections (e.g., a chart or a table) without affecting the rest of the page.