Typed link source survives the save only when it is not followed by a space

[Azganoth]

Summary

Typed link source is never recognized as a link, which is consistent on its own, but the serializer only escapes it when it ends the paragraph. Followed by a space, the same typed source is written to the file unescaped, so reloading the document turns text the editor deliberately kept literal into a link. The transient state and the reloaded state disagree, and which one wins depends on a trailing space.

Steps to reproduce

1. Open an empty document.
2. Type [test link](./test.html) and save. The saved source is escaped.
3. Open another empty document.
4. Type [test link](./test.html), then type one space, and save.
5. Reload the document.

Expected behavior

A typed source form reaches the same interpretation whether or not it is followed by a space, and the reloaded document matches the state the editor presented before the save.

Actual behavior

Measured against a61106a. None of these inputs is recognized while typing; the difference is what reaches the file:

Typed	Serialized result	On reload
[test link](./test.html)	\[test link]\(./test.html)	Literal text
[test link](./test.html)	[test link](./test.html)	Inline link
https://example.com	https\://example.com	Literal text
https://example.com	https://example.com	Autolink literal
<https://example.com>	\<https\://example.com>	Literal text
<https://example.com>	<https://example.com>	URI autolink

Plain-text paste recognizes all three forms immediately, and a pasted bare URL is rewritten to the angle-bracket form <https://example.com> rather than kept as the GFM autolink literal that was pasted.

Related context

• Related issues or pull requests: none
• Found through manual testing and revalidated against a61106a by driving the editor mount used by the plugin tests.

Done when

• A typed link, autolink literal, or URI autolink reaches the same interpretation with and without a following space, and the reloaded document matches what the editor presented before the save.
• Regression coverage asserts the serialized Markdown for each form in both positions.

Out of scope

• Whether typing link source should create a link at all, matching plain-text paste. Decide that separately; this issue is about the two typed paths disagreeing with each other.
• Whether a pasted bare URL should keep its GFM autolink-literal form instead of being rewritten to angle brackets.

[Azganoth]

Correcting the On reload column above before this closes: the two autolink rows are wrong.

https\://example.com reloads as a link, not literal text, with or without a trailing space. \<https\://example.com> reloads as a literal <, a link, and a literal >. Only the inline-link row behaved as the table describes.

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, so no source escaping survives that pass.

That makes the second half of the first Done when bullet unreachable from inside this issue: keeping a typed bare URL literal needs either recognition while typing or a parser change, and both are named in Out of scope above. #242 delivers what this issue states as its subject, the two typed paths disagreeing with each other, for all three forms. The remainder is tracked under #238.

Measured against a61106a by driving the editor mount used by the plugin tests.