Integrate `react-native-performance-stats` for Improved Performance Monitoring

### What is this about?

#### Description:
To improve performance insights and user experience, we should integrate the small library [`react-native-performance-stats`](https://github.com/hannojg/react-native-performance-stats) created by Hanno (a core member of Margelo). This will allow us to monitor and act upon frame rate (FPS) data in development, nightly, and potentially production builds. Proper FPS monitoring will help identify bottlenecks, improve performance, and provide more accurate telemetry of app behavior.

---

### Tasks:
1. **Display On-Screen Small FPS Counter (Dev/Nightly Builds)**
- Show an unobtrusive FPS counter on the screen during development and nightly builds to enable the team to notice FPS drops in real-time.
- This will serve as a visual aid to quickly identify when and where performance issues occur during rendering.

2. **Measure Average FPS After Login (15s Window)**
- Start measuring the average FPS after logging into the app.
- Include a measurement window of 15 seconds post-login (or another appropriate duration) to capture meaningful FPS data.
- Log or report the resulting average FPS, which will provide insights into the post-login app performance.

3. **Conditionally Mark Login as Completed Based on FPS**
- Update the current login performance metric logic to depend on FPS stability:
- Instead of marking the login process as completed when the dashboard is displayed, include an additional requirement for the JS thread's FPS to stabilize above a certain threshold.
- Example: Only mark login as "completed" if **average FPS exceeds 20 for at least 3 seconds**.
- This adjustment ensures that login telemetry reflects a valid "usable" state and avoids scenarios where the login process is marked complete but the app UI is frozen for the user.

---

### Context:
Currently, login completion is marked and sent to Sentry once the dashboard is displayed. This can produce misleading telemetry if the app is running at low FPS (e.g., 1 FPS) or if the JS thread is frozen. By incorporating FPS checks into our performance tracking, we can provide a more accurate measurement of the user experience.

---

---

### Open Questions:
- **Threshold Tuning**: Should the minimum FPS threshold and stabilization time (e.g., 20 FPS for 3s) be configurable for easy experimentation?
- **Automated Reporting**: Should we log/report FPS metrics (e.g., post-login average FPS) to an analytics service such as Sentry or a custom dashboard?
- **Production Consideration**: Would it make sense for the FPS counter or long-term FPS measurements to be optionally enabled in production for debugging purposes?

---

### Scenario

_No response_

### Design

_No response_

### Technical Details

_No response_

### Threat Modeling Framework

_No response_

### Acceptance Criteria

- [ ] FPS counter is displayed in development and nightly builds without interfering with the main app UI.
- [ ] Average FPS during the first 15 seconds post-login is measured and logged/reported.
- [ ] Login is only marked as "completed" and reported to Sentry if FPS conditions are met:
- Average FPS exceeds 20 for at least 3 consecutive seconds.

### Stakeholder review needed before the work gets merged

- [x] Engineering (needed in most cases)
- [ ] Design
- [ ] Product
- [ ] QA (automation tests are required to pass before merging PRs but not all changes are covered by automation tests - please review if QA is needed beyond automation tests)
- [ ] Security
- [ ] Legal
- [ ] Marketing
- [ ] Management (please specify)
- [ ] Other (please specify)

### References

- [react-native-performance-stats Documentation](https://github.com/hannojg/react-native-performance-stats)

Start by locating the current login performance metric flow, including where the dashboard display marks login complete and where the result is sent to Sentry. Read the react-native-performance-stats documentation and determine how its FPS counter and measurement window fit the development and nightly builds. Done means the listed FPS, reporting, and login-completion acceptance criteria are satisfied.

Written by the indexing model from the issue text.