fix(sanity): wrap sanityFetch in 'use cache' for cacheComponents compatibility

[arzafran]

What this does

/sanity and /sanity/[slug] were crashing at runtime with:

cacheTag() can only be called inside a "use cache" function.

This fixes both pages so they render again.

Root cause

next.config.ts enables cacheComponents: true (added in 50485f8, "test experimental setting"). next-sanity's sanityFetch (from defineLive) calls cacheTag() internally to register the cache tag for live revalidation — and under Cache Components, cacheTag() is only legal inside a 'use cache' function. The Sanity example pages called sanityFetch outside any 'use cache' scope, so they threw.

This was latent on main — not introduced by a recent PR. Confirmed by reverting the cache() wrapper from #204 to the prior direct calls: the error persisted, so React cache() was never the cause (it is not a 'use cache' boundary).

Fix

Wrap each fetch in a 'use cache' function — next-sanity's intended pattern under Cache Components (a cached fetch whose cacheTag is revalidated by <SanityLive>). For [slug], the slug is passed as an argument so the cache keys per article. This supersedes #204's React cache() approach and still satisfies its goal: 'use cache' also dedupes across the page render and generateMetadata, so the same document is fetched once per request.

Test Plan

• bun run check green — biome, tsgo --noEmit, 414 tests
• Runtime (dev): /sanity and /sanity/lorem-ipsum render with no console errors (previously both threw cacheTag())
• CI next build validates the prerender path under cacheComponents