Design an error.tsx hierarchy that fails at the right scope instead of taking down the whole page

You are designing the error-handling hierarchy for a route tree, deciding where error.tsx boundaries belong and what global-error.tsx is actually responsible for, so a failure in one section degrades only that section instead of crashing the whole page.

ROUTE TREE
app/layout.tsx (root) wraps app/dashboard/layout.tsx, which wraps app/dashboard/projects/[id]/page.tsx and app/dashboard/billing/page.tsx

FAILURE MODES TO HANDLE
A project id in the URL that doesn't exist or the user can't access; the billing page's payment-provider API occasionally timing out; a genuinely unexpected exception anywhere in the dashboard layout's own data fetch

CURRENT ERROR HANDLING
There's one error.tsx at app/dashboard/layout.tsx today — a billing API timeout currently crashes the entire dashboard, including the unrelated projects list

DESIGN RULES
Place an error.tsx at the route segment that actually owns the operation most likely to fail — a data fetch, a mutation — rather than only at the top of the tree, since an error.tsx catches errors thrown by anything beneath it in the same segment, including its own children, but a boundary placed too high catches the error just as correctly while taking a much larger, unrelated portion of the page down with it as collateral. Every error.tsx file must be a Client Component — it needs 'use client' at the top, since it receives an error object and a reset function as props and needs interactivity, specifically a retry button that calls reset(), to be useful rather than just a static message. Distinguish an expected, handled absence from a genuine unexpected error: calling notFound() for a resource that legitimately doesn't exist should render the segment's not-found.tsx, a deliberate, calm UI state, not error.tsx, which is meant for something that actually went wrong and wasn't supposed to happen; conflating the two means a normal, everyday case like a bad URL slug renders through the same alarming error UI as a genuine crash. Reserve global-error.tsx, which must live directly in the app directory and also be a Client Component, for errors thrown by the root layout itself — it's the only boundary that can catch a failure in the root layout, precisely because every other error.tsx in the tree is rendered as a child of that same root layout and therefore can't catch an error the layout itself throws before any child ever mounts. Log every caught error with enough context to actually debug it later — the route segment, the error's own message and digest if one exists, and any relevant identifiers from the request, such as which resource was being fetched — rather than only rendering a generic apology to the user with nothing captured server-side for whoever has to investigate the failure afterward.

OUTPUT FORMAT
A tree diagram showing where each error.tsx (and any not-found.tsx) sits, paired with what specifically triggers each one and what its fallback UI does — including whether it offers a retry via reset(). Close with one line confirming what global-error.tsx here is actually scoped to catch, and confirming it is not being relied on as a catch-all for errors that already have a more specific boundary lower in the tree.