Add a route-level error boundary to src/features/dashboard/Dashboard.tsx

[Jagadeeshftw]

📌 Description

src/features/dashboard/Dashboard.tsx is the top-level dashboard shell hosting all dashboard sub-pages. src/shared/components/ErrorBoundary.tsx exists (with a recovery-flow test from the prior round), but it's unclear whether Dashboard.tsx actually wraps its routed children with it — without that, an uncaught error in any single dashboard sub-page would blank the entire app rather than just that section.

🧩 Requirements and context

• Confirm/wire ErrorBoundary around the routed dashboard content in Dashboard.tsx (or DashboardLayout.tsx if that's the more appropriate boundary point).
• Add a test that throwing inside a child route is caught and shows the boundary's fallback UI, with the surrounding dashboard shell (sidebar/header) still intact.
• Add a 'reset' affordance so navigating away and back recovers without a full page reload.

Non-functional requirements

• Must be secure, tested, and documented.
• Should be efficient and easy to review.

🛠️ Suggested execution

1. Fork the repo and create a branch

git checkout -b fix/dashboard-route-level-error-boundary

2. Implement changes

• Modify: src/features/dashboard/Dashboard.tsx (or DashboardLayout.tsx) — wrap routed content with ErrorBoundary.
• Add test: extend src/features/dashboard/DashboardLayout.test.tsx or a new test on Dashboard.tsx.

3. Test and commit

• Run tests:

npm test -- run Dashboard

• Cover edge cases: error thrown during initial render of a sub-page, error thrown after a user interaction on a sub-page, navigating away from a crashed sub-page and back.
• Include test output and details in the PR description.

Example commit message

fix: wrap dashboard routed content in an error boundary to contain per-page crashes

✅ Acceptance criteria

• An error in one dashboard sub-page shows the boundary fallback while sidebar/header/navigation remain usable.
• Navigating to a different route after a crash recovers cleanly.
• Non-erroring sub-pages are entirely unaffected.

🔒 Security notes

Containing crashes prevents a single buggy widget from fully denying dashboard access, which matters for maintainer-facing workflows (approving applications, managing projects) that shouldn't all go dark from one bad component.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours