fix(frontend): stop the ErrorBoundary fallback from re-rendering AppShell

[DSOTec]

Problem

At its only call site the tree is:

<ErrorBoundary>
  <AppShell>
    …dashboard content…
  </AppShell>
</ErrorBoundary>

AppShell therefore renders inside the boundary, which makes it one of the components that can throw. But the fallback wrapped its error UI in AppShell again:

if (this.state.hasError) {
  return (
    <AppShell>
      …"Something went wrong"…
    </AppShell>
  );
}

So an error originating in AppShell itself — the nav, search, or wallet-connect render path — was caught, and then thrown a second time while rendering the fallback. That second throw has no ancestor boundary left to catch it, so React unmounts the whole tree: the page blanks entirely instead of degrading to "Something went wrong", which defeats the point of the boundary.

Solution

Render a plain, self-contained fallback: no AppShell, and no other app component. The AppShell import is dropped entirely so the fallback cannot regress into depending on app code again.

AppShell's outer chrome is inlined (min-h-screen px-6 py-8 sm:px-10 bg-ink dark:bg-black, plus the mx-auto max-w-6xl container) so the fallback still renders as a proper page rather than unstyled content on a bare background.

Errors thrown by page content — the common case — behave exactly as before.

Testing

Added frontend/src/components/error-boundary.test.tsx with 6 tests. AppShell is mocked behind a flag so a test can make it throw, which is the precise scenario this issue describes:

1. children render when nothing throws
2. the fallback renders when page content throws
3. the boundary still degrades gracefully when AppShell itself is the error source — render() must not throw
4. the fallback does not mount AppShell — asserted via a data-testid that must be absent
5. the error message is surfaced in the details panel
6. "Try again" resets and re-renders the children

Verified the tests actually catch the bug. Against the previous implementation, tests 3 and 4 fail with the error escaping the boundary:

× still degrades gracefully when AppShell itself is the error source
  → expected [Function] to not throw an error but 'Error: AppShell exploded' was thrown
× renders a fallback that does not mount AppShell
  → AppShell exploded

The other four pass both before and after, confirming the change is targeted and does not alter existing behaviour.

Full suite from a clean npm ci, matching what CI runs:

npm test          13 files, 109 tests passed   (also verified with CI=true)
npm run lint      0 errors
npm run build     OK
npx tsc --noEmit  clean
npx playwright test   2 passed
npx lhci autorun      exit 0 (warnings only, no failed assertions)

Edge cases considered

• Styling drift: the fallback now duplicates AppShell's outer <main> classes. That duplication is deliberate — the whole point is that the fallback must not depend on AppShell — but it does mean a future change to the app background would need mirroring here. The alternative (extracting a shared layout primitive) would reintroduce a shared dependency in the fallback path, so I kept it inlined.
• Loss of nav in the fallback: the fallback no longer shows the header nav. That is the intended trade-off; it already offers "Try again" and "Go home", which cover navigation without depending on the component that may have thrown.
• Other call sites: ErrorBoundary is used in exactly one place (dashboard/[username]/page.tsx), so nothing else relied on the fallback providing AppShell chrome.

Note on the first commit

This branch carries two commits. The second is the actual fix for #1062 — a 9-line change to error-boundary.tsx plus its tests.

The first is the CI-pipeline repair already submitted as #1071, included only because main is currently red: Frontend CI, Lighthouse CI and E2E (Playwright) all fail on main, so a branch based on it cannot go green on its own. If #1071 merges first, I'll rebase and that commit disappears from this PR. Reviewing error-boundary.tsx and error-boundary.test.tsx alone gives the complete picture of this fix.

Closes #1062

[drips-wave]

@DSOTec Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits