Record what a deferred delimiter pair costs at save time

[Azganoth]

Summary

A delimiter pair whose closing run is the shorter one is read once the caret leaves that run, which docs/specification.md states and docs/decisions.md gives the rationale for. Neither records what that costs at save time: two saves with no edit between them write different files. Nor does either say why a pending pair is left unfinalized when a projection is finalized, which is the rule stated a few entries away.

A reader who reaches this from the serializer finds the behavior and its rationale, and no answer for either question.

Documents or locations

• docs/decisions.md#L154, the entry beginning The pairing waits where the closing run is shorter than the run it would pair with
• docs/decisions.md#L181, the entry Projection finalizes before serialization
• docs/specification.md#L156, the entry describing how a delimiter typed to close a run of literal text pairs with the run that text opens

Current documentation

docs/specification.md states that where the closing run is the shorter one the pair is read once the caret leaves it. docs/decisions.md records why: the continuations are each other, so firing on the keystroke serves ***text* at the cost of ***text**, and deferring serves both.

Neither records the consequence. A run still open to growth is saved as the literal text it is, so saving before the caret moves and saving after it moves produce different files with no edit between them. #346 recorded this in its own notes and deliberately added no save-time finalize, but a pull request body is not where a reader looks for it.

docs/decisions.md separately states Projection finalizes before serialization. That is a pending state that is finalized before a save; a pending pair is a pending state that is not. Nothing records why the two differ, so the difference reads as an oversight rather than a decision.

Intended change

Record beside the existing pairing decision:

• that a pair still open to growth is written as the literal text it is, so the file a save writes depends on whether the caret has left the run;
• that this is accepted because the file matches what the editor shows and reopens as the document that wrote it, so it costs neither content nor closure under Preserve the form a file was written in;
• why a pending pair is not finalized before serialization where a projection is.

Related context

• Related issues or pull requests: Typing nested emphasis delimiter runs leaves literal text or duplicates runs #232 is the defect the pairing fixed, and fix: pair a delimiter run typed into literal text with the run that text opens #346 is the pull request whose notes carry the consequence this issue moves into the documentation. docs: record what a save preserves and what it normalizes #348 settled the content, closure, and form order this is judged against.
• Documentation, decisions, or prior investigation: docs/decisions.md under Preserve the form a file was written in.

Done when

• docs/decisions.md records the save-timing consequence and why it is accepted.
• docs/decisions.md states why a pending pair is not finalized before serialization where a projection is, or the two are made consistent instead.
• The pairing entry in docs/specification.md and the decision entry agree with each other and with the behavior below.

Notes

Measured at 83033d4b by driving the editor mount used by the plugin tests: typing into an empty paragraph that does not share its block with the tail, saving, then moving the caret into the tail paragraph and saving again, with no edit between the two saves.

Typed	Saved with the caret on the run	Saved after the caret leaves	Same file
***text*	\*\*\*text*	\*\**text*	no
_**text*	_\*\*text*	_\**text*	no
*__text_	*\_\_text_	*\__text_	no
_**text**	_**text**	_**text**	yes
_**text**_	_**text**_	_**text**_	yes

The three that differ are the rows where the closing run is the shorter one, which is exactly where the pairing defers. Each first file reopens as the literal document that wrote it, so closure holds in every row.