Normalised curation-history prose would read better as block scalars (|)

[realmarcin]

Raised in review of PR #344 (#322's corpus normalisation). Deliberately not done there —
it changes the emitted format, which would mean re-normalising all 477 records inside a PR
already under review.

The observation

safe_dump's default for a long string is a folded/wrapped plain scalar, so the ~50
curation_history.changes entries — which are multi-sentence prose explaining why a
change was made — now come back re-wrapped at the emitter's width:

  changes: Re-grounded 2 causal edge(s) off enables/RO:0002327 with a TRAIT object (1
    to has electron acceptor, 1 to confers), issue 302. RO:0002327 has range 'biological
    process or activity', which a trait (a disposition) cannot satisfy, so the previous

A str representer emitting block literal style (|) for multi-line or long values
would keep them readable and, more usefully, make their diffs line-oriented — an edit to one
sentence would show as one changed line rather than re-flowing the whole paragraph.

Why it wasn't done in #344

• It changes EMIT_OPTS/the representer, so every record would need re-normalising again.
• test_the_whole_corpus_round_trips would enforce whatever form is chosen, so the decision
  is one-way once taken — worth making deliberately rather than inside a 350-file PR.
• Normalise the corpus so the round-trip claim becomes enforceable (#322) #344's property (byte-identical round-trip) holds either way; this is about which stable
  form to standardise on.

If taken

1. Register a representer for str choosing | when the value contains a newline or
   exceeds some length.
2. Re-run the normaliser (scripts/-side, two-pass with the semantic check as in Normalise the corpus so the round-trip claim becomes enforceable (#322) #344).
3. The existing round-trip tests then enforce the new form with no change.

Worth checking the diff-noise claim first on one record, since block scalars are also
whitespace-sensitive in a way plain scalars are not.

[realmarcin]

Closing as won't do — I measured the claim this rests on and it goes the other way.

What I tested

Added a str representer emitting | for values over 120 chars or containing a newline,
dumped metabolism/acetogenesis.yaml both ways, then made a one-word edit near the start
of a curation_history.changes paragraph and diffed:

form	diff lines for a one-word edit	longest line in file
current (plain, wrapped)	2	99
block scalar |	4	1713

Block scalars are worse on both counts the issue predicted they'd improve.

Why

Block literal style preserves the string exactly. These changes values are
single-line strings — there are no newlines in the data; the line breaks you see today
are safe_dump wrapping at emit time. So | faithfully reproduces one ~1700-character
line, which is neither readable nor line-diffable.

Getting line-oriented diffs would require the stored strings to contain newlines. That is
a change to the data, not the formatting — and #322's whole guarantee was that the
normalisation altered formatting only, verified three ways. Trading that for prettier prose
is a bad swap.

What would actually help, if this bothers anyone

Tune width in EMIT_OPTS rather than the style — a narrower width gives shorter lines and
so finer-grained diffs, and stays a pure formatting change that
test_the_whole_corpus_round_trips would enforce. Cheap to try, and reversible.

Good suggestion to have raised, and the issue was right that it needed checking on one record
first — that check is what killed it, before it cost 477 files.