Move getPosts call out of ui/sections/blog-post-list into the page entry point

[ooloth]

Why

A presentational section component that fetches live Notion data conflates data-fetching with rendering, prevents isolated testing without network access, and duplicates fetch logic that already belongs at the page level.

Current state

ui/sections/blog-post-list.tsx imports getPosts from @/io/notion/getPosts (line 3) and calls (await getPosts({ … })).unwrap() (line 30) inside the component. A section component is performing a live Notion API call that belongs at the page entry point (app/blog/page.tsx).

Ideal state

• PostList (or the blog-post-list section component) accepts an already-fetched PostListItem[] prop and contains no imports from @/io.
• app/blog/page.tsx calls getPosts and passes the result as a prop to the section component.
• The section is renderable in tests with plain props and no network access.

Starting points

• ui/sections/blog-post-list.tsx — line 3 (import) and line 30 (call) to remove; component signature to update
• app/blog/page.tsx — the correct location for the getPosts call
• io/notion/getPosts.ts — the fetch function

QA plan

1. Open ui/sections/blog-post-list.tsx — expect no imports from @/io and a posts: PostListItem[] prop in the component signature.
2. Open app/blog/page.tsx — expect getPosts called here and the result passed to the section component.
3. Run npm run build and npm run test:ci — expect no regressions.

Done when

ui/sections/blog-post-list.tsx contains no @/io imports, accepts a posts prop, and the blog page continues to render correctly.

[ooloth]

Carrying forward the one detail from #155, which is being closed as a duplicate of this issue and #59.

Once both this and #59 have landed, a page that renders Header and PostList should make a single getPosts call and pass the result to both, rather than one call per component. Today app/(home)/page.tsx triggers two calls in a single render, from ui/layout/header.tsx:5 and from ui/sections/blog-post-list.tsx:30. Both are served from the same cache key, so the duplication is currently cheap, but it stops being obvious that it is cheap once the fetch moves up.

#155 also recorded two out-of-scope notes that apply here: getPosts itself and the Notion client are not changed by this work, and build-time caching behaviour is tracked separately in #112.

[ooloth]

Done in d1ba366 and a6b4f02.

ui/sections/blog-post-list.tsx now takes posts: readonly PostListItem[] and renders it. app/blog/page.tsx and app/(home)/page.tsx each call getPosts once and pass the result down, with the home page slicing to its own limit. The limit prop and the unused skipCache prop are gone, and the component is no longer async.

One deviation from the wording of this issue, worth recording rather than glossing: the file still contains import { type PostListItem } from '@/io/notion/schemas/post'. The done-when here asked for no @/io imports at all, but that is not achievable, because @/io/notion/schemas/post is where the type is defined. It is also already what ui/sections/post-pagination.tsx:3 and ui/layout/header-nav.tsx:7 do. The runtime import and the live Notion call are what this issue was about, and both are gone.

Rendered output is unchanged, verified by comparing the post list markup, hrefs, datetimes and titles against the previous build.