[ericof]

Adds an opt-in block converter for <pre>. Three inputs reach the HTML step as <pre>: Markdown fences, indented code (<pre><code> without a class) and HTML <pre>. Each becomes a codeBlock block of @plonegovbr/volto-code-block.

Setting. volto_blocks(), html_to_blocks() and markdown_to_blocks() take code_block. Pass a dict to enable the conversion. Its keys style, wrapLongLines and showLineNumbers override the defaults (dark, True, False). An empty dict enables it with the defaults. The convert command takes --code-block, plus --code-style, --wrap-long-lines/--no-wrap-long-lines and --show-line-numbers/--no-show-line-numbers, which require --code-block. The HTTP service is unchanged.

Language. Read from a language-* or lang-* class on the <code> or the <pre>, lowercased. shell, sh and console map to bash, and py to python. Without a language the block gets text. The code is the element text without one trailing newline.

Why opt-in. codeBlock comes from an add-on, not Volto core, so sites without it would get blocks they cannot render. With the option off, the <pre> converter is hidden during the conversion. This is needed, not just a default: registering a block converter for <pre> changes how the parser splits paragraphs and unwraps containers, so the default layout is pinned in tests for <pre> inside paragraphs, divs and sections.

Open questions

• Should POST /volto and POST /markdown take the option now, or wait for a consumer?
• Should the defaults move to settings rather than fixed values in code?
• Is text the right fallback for a plain <pre>, or should it be plaintext?
• Which further aliases should map (js, ts, yml, html)?

Closes #47