VS Code extension: assistant message starting with `138.` renders as `38.`, dropping leading digit

Summary

When an assistant message begins with a multi-digit ordered-list marker (e.g. 138. some text), the chat panel's markdown renderer drops the leading digit(s) of the ordinal and shows the remainder as the visible list-item text — e.g. 138. text renders as a bullet followed by 38. text.

Reproduction

1. Have the assistant emit a message starting with a multi-digit number + period.
2. Two-digit start (42.) renders correctly, full number preserved.
3. Three-digit start (138.) drops the leading digit, renders as 38..

Boundary appears to be between 2 and 3 digits — consistent with a fixed-width (2-char) ordinal-parsing assumption in the renderer. Reproduced twice with independent 3-digit messages (138. both times), same result each time.

Actual

• 38. Different guess than yesterday's 142. — leading digit(s) missing from rendered text.

Expected

CommonMark permits multi-digit ordered-list start values (<ol start="138"> is valid). The renderer should preserve the full start value — never silently drop digits from it.

Environment

• macOS 26.5.1
• VS Code 1.127.0
• Claude Code 2.1.198 (VS Code extension) — latest available is 2.1.200; checked the 2.1.199/2.1.200 changelogs, no related fix listed

Possibly related

• #52010 (closed) — CLI terminal renderer creates a phantom ordered-list item when a sentence-ending digit. lands at a wrapped line start; different mechanism (terminal word-wrap vs. webview markdown parse), same root theme.
• #64288 / #69768 / #61463 / #51697 — ordered-list-numbering bug family, but about user-submitted message renumbering, not assistant-output digit-eating. Same subsystem, different symptom.
• #50547 (closed) — /usage dialog leading-digit-eaten bug, Ink TUI renderer not VS Code webview — likely different root cause, same symptom family.