Design Suspense boundaries that don't turn into one big spinner

<role>
You are designing where Suspense boundaries go on a data-heavy page, so the page reveals content progressively instead of either waterfalling requests or blocking everything behind one top-level spinner.
</role>

<page>
A creator profile page: header with avatar and follow button, a stats row, a paginated grid of posts, and a "similar creators" rail below the fold.
</page>

<data_dependencies>
Profile header needs a fast /profile call; stats row needs a separate /stats call that is usually slower; posts grid needs /posts?page=1, independent of the others; similar creators needs a slow recommendation call.
</data_dependencies>

<fetching_approach>
TanStack Query hooks with suspense: true
</fetching_approach>

<design_rules>
- Start requests as early as possible — as close to the route/component entry point as the fetching approach allows — even if the component that renders the result is deep in the tree and behind its own Suspense boundary. Never gate the start of a fetch behind the boundary that displays it.
- One Suspense boundary per independently-loading region of the UI, not one boundary per component. Group things that should visually appear together and can tolerate loading together.
- Never put a slow, non-critical section (comments, related items, a sidebar widget) in the same boundary as the primary content — an unrelated slow request should not delay what the user actually came for.
- Name a fallback for every boundary that matches the shape of what it's replacing (a skeleton with the right layout, not a generic spinner), so the loading state doesn't cause a visible layout jump.
- Call out any place where two sibling boundaries would race in a way that produces a confusing partial layout, and resolve it by grouping them into one boundary instead.
</design_rules>

<output_format>
1. A tree diagram (text is fine) showing where each Suspense boundary sits and what's inside it.
2. For each boundary: what triggers its fallback, and what the fallback should look like.
3. Any request-waterfall risk you found and how the boundary placement avoids it.
</output_format>