Markdown renderer draws the closing code fence inside the block when the message ends exactly at the fence

[Adam-Dalloul]

codeg v0.28.0, Windows 11, codex agent (but the bug is in the renderer, not the agent).

Symptom

A message that ends with a fenced code block renders the CLOSING fence as a second content line inside the block, with the caret sitting after it:

1  e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
2  ```_

The raw source is valid

I pulled the exact assistant text from the agent's session file on disk. The message tail is well-formed and ends immediately after the closing fence, with no trailing newline:

SHA-256:\n\n```text\ne3b0c442...52b855\n```

So the parser fails to terminate the block when the closing ``` is the final bytes of the message (no \n after it), and prints the backticks as code content instead. A block with any text following it in the same message renders fine.

Cosmetic only, but it makes copy-buttoned output (hashes, keys, one-liners) look wrong and the copied text can include the stray fence line.

Repro: have any agent reply with a message whose last characters are a closing fence, e.g. exactly:

SHA:

```text
abc123
```

[Adam-Dalloul]

Dug further so this lands with more than a screenshot. What I ruled out, driving the real components under vitest/jsdom at streamdown 2.2.0:

• The raw assistant text on disk is valid markdown and ends exactly at the closing fence, no trailing newline.
• normalizeMathDelimiters returns it byte-identical (no math-fence pad injected).
• <Streamdown> bare AND codeg's full MessageResponse pipeline (remark chain + rehype allow-codeg) render it correctly, both as one shot and re-rendered char by char to the exact final string: the code block contains only the hash, no fence line.

So the symptom is not the parser given correct final input. What is left is the live path in the packaged app: the streaming cadence plus whatever renders the caret that is visible after the stray fence in the screenshot (my headless harness cannot drive that layer). Happy to test a dev build or add instrumentation if useful.

[Adam-Dalloul]

Found it, and it is not a fence parser bug. Same cause as #487.

Streamdown defaults to mode="streaming" with parseIncompleteMarkdown, so remend runs on finished bubbles too. The reply mentions _meta-style tokens earlier, remend appends a _ closer at the end, that _ lands after the final ```, the fence stops closing, and the backticks render as code content.

My earlier isolation missed it because I tested the tail alone. The tokens earlier in the message are what arm remend.

Truth table on the real reply, driving MessageResponse under vitest:

mode	parseIncompleteMarkdown	result
streaming	true	reproduces
streaming	false	clean
static	true	clean
static	false	clean

#487 already sets both safe defaults, so it fixes this. Pushed a regression test for this shape onto that PR.