Bot-aware SEO should cover `seo=true` sections, not just `page.seo`

blocks: bot-aware SEO should cover seo=true SECTIONS, not just page.seo

Repo: decocms/blocks (@decocms/blocks)

Problem

setAsyncRenderingConfig({ botAwareSeo: true }) strips commerce-loader props for
human requests ONLY in resolvePageSeoBlock (the page.seo field). Sites
migrated from deco-cx (Fresh) emit JSON-LD via sections marked
export const seo = true (e.g. PageSEO.tsx, CustomSEOPLP.tsx), placed in the
sections array — NOT via page.seo. For those sites botAwareSeo does nothing,
so every human still gets the full schema.org JSON-LD serialized into the
hydration payload.

Reference: src/cms/resolve.ts — resolvePageSeoBlock / stripCommerceLoaderProps
apply only to page.seo (line ~1213); isSeoSection / registerSeoSections
handle section-level SEO but without any bot-aware strip.

Impact

On miess-01-tanstack the seo=true SEO section serialized the full
ProductListingPage/Product JSON-LD (~900 KB–1.2 MB) for every human. Worked
around at site level by gating the JSON-LD build on isEagerRequest(...) inside
each SEO section's loader.

Proposed fix

Either (a) extend the bot-aware strip to seo=true sections whose props resolve
to a commerce loader, honoring the same botAwareSeo flag; or (b) document
isEagerRequest as the supported pattern for section-level SEO gating (it is
already exported from @decocms/blocks/cms).

Opt-in requirement

Same as page.seo bot-aware: default off, opt-in per site, so no site regresses to
a generic <title> / missing structured data on a framework bump.

Start in src/cms/resolve.ts by reading resolvePageSeoBlock, stripCommerceLoaderProps, isSeoSection, and registerSeoSections to compare page.seo handling with seo=true sections. Check how botAwareSeo and the exported isEagerRequest pattern apply to section-level SEO; done means either section props receive the opt-in bot-aware behavior or the supported gating pattern is documented without changing the default.