fix(chat): restore fenced code blocks (placeholder used escaped backslashes)

[tomekpanek]

Problem

renderChatContent extracts ```fenced``` blocks and replaces each with a sentinel containing real NULL bytes:

return `\x00CODE${id}\x00`;     // \x00 = U+0000 (one byte)

The restore step searches for the literal-text version of that string instead:

html.replace(`\\x00CODE${i}\\x00`, '<pre>...</pre>');
//             ^^                ^^   inside a template literal these are
//                                    backslash + 'x' + '0' + '0', not U+0000

So the needle never matches the sentinel actually present in html. The unreplaced sentinel reaches element.innerHTML = ...; per the HTML spec the parser drops U+0000 characters, leaving the visible text CODE0, CODE1 … inside the rendered message.

fixCodeBlockContent can't recover because it looks for __CODE_CONTENT_${i}__ inside <pre><code> — but those wrappers are never produced when the upstream replace silently fails.

Repro (deterministic)

Any reply containing a fenced code block reproduces the bug. Verified with a small Node script:

INPUT : Has ```\n/path/foo\n``` inline
VISIBLE: Has CODE0 inline

INPUT : Multiple ```\nblock1\n``` and ```\nblock2\n```
VISIBLE: Multiple CODE0 and CODE1

Confused users then ask the model what CODE0 means; the model has no idea and starts hallucinating explanations from its own corrupted history.

The SQLite DB row content has the original markdown with backticks intact — this is purely a render-side regression, no data corruption.

Fix

Drop the extra backslashes so the search needle is the NULL-bracketed sentinel that step 1 actually inserts.

Regression source

Introduced in 6b54d8b (v3.6.0) when renderChatContent was extracted into src/js/chat/cli.js and the __CODE_CONTENT_${i}__ two-stage hand-off was added.

Verified by

Tested locally on top of v3.6.0 — historical sessions that previously showed CODE0/CODE1 now render the original code blocks correctly.