RSS generation fetches Notion block children sequentially — N serial API calls for N posts

[ooloth]

Current state

app/rss.xml/route.ts fetches Notion block children for each post inside a for...of loop, serialising N Notion API calls one after another. For a site with many posts, RSS generation time scales linearly with post count and with Notion API latency.

Ideal state

• Block children for all posts are fetched concurrently via Promise.all (or Promise.allSettled).
• Total RSS generation time is bounded by the slowest single Notion response, not the sum of all responses.
• Individual fetch failures are surfaced per-post rather than aborting the entire feed.

Out of scope

• Caching block children across builds (tracked separately in Build-time cache disabled in production — every static page generation hits Notion API fresh #112 / Persist build-time API cache across deploys to avoid refetching all external data on every build #143).

Starting points

• app/rss.xml/route.ts — the for...of loop around getBlockChildren (lines 25–46)
• io/notion/getBlockChildren.ts — the underlying fetch to parallelise

QA plan

1. Open app/rss.xml/route.ts. Expect to see a for...of loop calling getBlockChildren sequentially for each post.
2. After the fix, read the implementation. Expect a single Promise.all (or Promise.allSettled) call wrapping all getBlockChildren invocations.
3. Run npm run build (or next build). Expect the RSS route to build without errors.
4. Visit /rss.xml in the built output. Expect a valid RSS feed containing entries for all published posts.

Done when

getBlockChildren is called for all posts in parallel during RSS generation, with no sequential await inside a loop over post items.