Refactor Pages to Separate Business Logic from UI Rendering Using Custom Hooks

### Description

### **Description:**

Many pages in the current codebase, such as `Dashboard.tsx`, follow a **monolithic component structure** where **UI rendering** is tightly coupled with **business logic** (e.g., API calls, state handling, toggles, etc.). This makes the components hard to maintain, test, and scale.

This ticket aims to **refactor these pages** by introducing **custom hooks** that encapsulate business logic and state management. The goal is to achieve **separation of concerns** and improve **code reusability, readability, and testability**.

### Acceptance Criteria:

* [ ] Each page with mixed business logic and UI should be analyzed and refactored.
* [ ] Create and use custom hooks (e.g., `useBalance`, `useTransactions`, `useMenuToggle`) to handle state and side effects.
* [ ] Ensure UI components become lean, declarative, and focused only on rendering.
* [ ] Reuse logic hooks across similar components if applicable.
* [ ] Maintain existing functionality and behavior with zero regression.
* [ ] All logic previously handled inside the component (e.g., fetching, toggling, managing visibility) must be abstracted into hooks.

### Subtasks:

1. **Audit all pages/components** with tightly coupled logic/UI.
2. **Create reusable custom hooks** to handle:

* Balance fetching
* Transaction fetching
* Bottom sheet/menu toggle
* Any other repeated stateful logic
3. **Refactor `Dashboard.tsx`** to use custom hooks.
4. **Refactor additional pages** using the same pattern.
5. **Test all affected pages** to ensure consistent UX and error handling.
6. **Code review and clean up**.

### Notes:

> This pattern should be **applied project-wide**, especially in any page/component where:
>
> * Business logic (API calls, toggle states, async functions)
> * UI rendering (JSX)
> ... are tightly coupled in the same file.

Refactoring should adhere to **feature-based architecture** principles and consider **future scalability**.