fix: keep typed link source literal when a space follows it

[Azganoth]

Summary

Typed link source was written to the file as live Markdown whenever a space followed it, so text the editor deliberately kept literal became a link on the next open. The same source ending the paragraph was escaped. Which of the two states won depended on a trailing space.

The cause is Milkdown's own text stringify handler, installed through remarkStringifyOptionsCtx:

if (/^[^*_\\]*\s+$/.test(value)) return value;

Any value ending in whitespace and free of *, _, and \ is returned without escaping. This is not specific to links — it disables escaping for the whole value, so #, >, `, and | at a position that needs escaping were affected the same way. mdast-util-to-markdown escapes both forms correctly on its own; serializing the same mdast directly confirms it.

Leafdown now installs its own handler. It escapes the value up to its trailing whitespace through state.safe and appends that whitespace raw, which keeps Milkdown's reason for the bypass — safe encodes a space before a line ending as  , and an ordinary typed trailing space should not produce that.

Typed source now serializes identically in both positions:

Typed	Serialized
[test link](./test.html)	\[test link]\(./test.html)
[test link](./test.html)	\[test link]\(./test.html)
https://example.com	https\://example.com
https://example.com	https\://example.com
<https://example.com>	\<https\://example.com>
<https://example.com>	\<https\://example.com>

Related Issue

Closes #234

Verification

Focused tests in markdownCompatibility.test.tsx assert the serialized Markdown for the inline link, autolink literal, and URI autolink, typed at the end of a paragraph and typed with a space after it. A reload test asserts that the escaped inline-link output parses back to literal text with no anchor, in both positions. A further test asserts an ordinary trailing space is still written as itself rather than  , which is the behavior Milkdown's bypass existed to protect.

pnpm check:frontend passes. The backend is untouched.

Not verified: manual Tauri verification was not performed. The change is serialization, exercised through the real editor mount in the automated tests.

Notes

#234's second Done when bullet is met in full. The first is met except for one clause, and that clause cannot be met inside #234's own scope.

The issue's On reload column is wrong for the two autolink rows. https\://example.com — the escaped output the editor already produced at a61106a — reloads as a link, with or without a trailing space, and \<https\://example.com> reloads as a literal <, a link, and a literal >. mdast-util-gfm-autolink-literal runs transformGfmAutolinkLiterals, a findAndReplace over mdast text values after parsing, once escapes and character references are already decoded; https\://example.com relinks too. No source escaping survives that pass.

So "the reloaded document matches what the editor presented before the save" was written believing autolinks already round-tripped as literal text. Reaching it needs either recognition while typing or a parser change, and #234's Out of scope section rules out both. The clause is unsatisfiable within the issue that states it, so it is tracked under #238 rather than held against this one.

What #234 names as its subject, "the two typed paths disagreeing with each other", is delivered for all three forms.

Two consequences worth review:

• Leading whitespace is now escaped consistently, so " leading and trailing " serializes as  leading and trailing . The bypass previously left it raw only when the value also ended in whitespace, which was already inconsistent with the same value without a trailing space. A raw leading space is dropped on reload, so this is a correction, but it changes bytes written for a paragraph that starts with a space.
• Typing <https://example.com> now writes \<https\://example.com> rather than the valid URI autolink it happened to produce before. That is the point of the fix, since the editor showed literal text, but it changes saved output for that sequence.

The handler's type is derived through remarkStringifyOptionsCtx._typeInfo because remark-stringify is not resolvable from src/ under pnpm's strict layout. A change to that slice's shape surfaces as a type error rather than silent breakage.