✅ Local verification — LGTM

Built and ran real tests for this PR in an isolated git worktree checked out at the PR head (6b4552d5c), Node v22.22.2 / Vitest 3.2.4. Verdict: the fix is correct and the new test genuinely guards it. Safe to merge.

What the fix does

In splitChunks, when a fenced code block crosses the 3800-char boundary the next chunk reopens the fence. The buggy reset used a value already ending in a newline, and the subsequent line-append (buf += (buf ? '\n' : '') + line) added a second \n because buf was already truthy. The continued chunk therefore began with fence + blank line, rendering as spurious leading whitespace inside the code block. The fix drops that trailing newline so the existing append contributes the single separator:

-      buf = inCode ? '```\n' : '';
+      buf = inCode ? '```' : '';

A/B test — the new test actually catches the bug

Same PR test file; only the 1-line source fix was toggled:

Failure on the buggy source:

× splitChunks > reopens code fences without inserting a blank line
  → expected true to be false   // chunks[1].startsWith(fence+'\n\n') === true
  ❯ src/markdown.test.ts:104:48

This is the meaningful proof: the new test fails before the change and passes after, so it is a real guard rather than a tautology.

Behavioral A/B on the real splitChunks module

Input: one code block over the limit (fence + x\n×2000 + fence) → 2 chunks. Inspecting the raw start of chunks[1]:

PRE-FIX  : "```\n\nx\nx"   hasBlankLine=true    L1 = (blank)  ← spurious whitespace
PR FIX   : "```\nx\nx\n"   hasBlankLine=false   L1 = x        ← code starts immediately

Why the existing test didn't catch it

The pre-existing boundary test asserts chunks[1].trimStart().startsWith(fence) — trimStart() strips the leading blank line, so it was structurally blind to this bug. The new test uses raw startsWith, closing that gap.

Scope / risk

• One-line change, confined to the inCode branch of splitChunks (DingTalk channel only). The non-code reset (: '') is untouched.
• Full @qwen-code/channel-dingtalk package suite: 17/17 passing on the restored PR head.
• No other test files in the package; no collateral.

-      buf = inCode ? '```\n' : '';
+      buf = inCode ? '```' : '';

× splitChunks > reopens code fences without inserting a blank line
  → expected true to be false   // chunks[1].startsWith(fence+'\n\n') === true
  ❯ src/markdown.test.ts:104:48

修复前 : "```\n\nx\nx"   hasBlankLine=true    第1行 = (空行)  ← 多余空白
PR修复 : "```\nx\nx\n"   hasBlankLine=false   第1行 = x        ← 代码紧跟围栏

_{Verified locally via tmux in an isolated worktree (A/B: only the 1-line fix toggled). Logs: post-fix 17/17, pre-fix 1 fail @ markdown.test.ts:104.}