Function render_blocks 

pub fn render_blocks<H: RenderHooks + ?Sized>(
    hooks: &H,
    out: &mut String,
    blocks: &[Block],
)

Render a sequence of blocks to HTML. Used by shortcode-body renderers — grid cells and, via src-tauri’s render_hero_html_typed (Phase 4 PR4.5), the hero overlay — to render a Vec<Block> that didn’t come from a full Document. render_document does NOT call this: it walks its blocks and meta in lockstep, calling render_block directly.

Not table cells. A Block::Table holds Vec<Vec<Vec<Inline>>> — its cells are inlines, rendered by render_inlines inside the table arm, so they never reach any block-level entry point. Listing them here (and in ADR-035) described a caller that cannot exist.

Source-line caveat: this entry point has no per-block meta vec, so every block renders without data-source-line. Callers that need source-line annotations must walk meta-block pairs themselves (see render_document). Today only render_document consumes meta; nested-block walks (list items, callout bodies, blockquotes) are also meta-free — data-source-line is a top-level-block-only concern, matching the legacy transform_events emit shape.

H: ?Sized so the function can be called with &dyn RenderHooks or with self: &Self from inside a trait default method (where Self is not statically Sized). The hook surface is a thin dispatch boundary; monomorphization across all concrete impls is not required. Footnote caveat: this entry point carries no [FootnoteIndex], so a marker inside blocks renders as its literal [^label] source and a definition renders in place. That is the honest shape for the callers this function has — shortcode bodies, which are their own little documents with no endnote section of their own. Nested walks INSIDE a document use render_blocks_with. ADR-035 § Three call paths.