Add YAML CST as a pipeline source and harden the CST surface (kyo-schema)

[DamianReeves]

Problem

kyo-schema gained YAML support, including an opt-in concrete syntax tree (CST) that preserves comments, trivia, scalar styles, and source spans. Two gaps remained after the initial CST work:

1. Correctness and clarity issues in the CST surface surfaced by review: block scalars were corrupted on the trivia render path, structural edits silently acted on the first of duplicate mapping keys, complex collection keys rendered a debug toString, and processor-backed cstAll could diverge in document count from the source-backed path.
2. A CST could be produced (parse, edit, render) but could not be consumed: nothing accepted a Yaml.Cst.Document/Yaml.Cst.Stream as a decode/render/visit source, so a parsed-and-edited CST had to be rendered back to text and re-parsed to decode it.

Solution

Two themes.

CST hardening:

• Render block scalars (|/>) on the trivia path instead of double-quoting them, reusing the writer's appendBlock (with a headerSuffix so trailing comments survive on the header line).
• Fail clearly on ambiguous edits: duplicate mapping keys along an edit path error instead of editing the first match; insert fails on an existing key rather than overwriting.
• Render complex collection keys as valid flow YAML rather than a node toString.
• Align processor cstAll with the source-backed path (drop a leading marker-only segment), and document that cstAll returns every document.
• Test hygiene: group multi-assert YAML tests into single assertResult blocks over named tuples.

CST as a source (new capability):

• YamlCstBuilder emits events from a CST (emitDocumentBody/emitStream).
• Yaml.Pipeline gains CST-source overloads: visit, render, parse, parseAll, decode, decodeAll over Cst.Document/Cst.Stream. Stream decoding honors ReaderConfig.documentIndex/documentMode exactly as the String path (same precedence, same error messages), including a CST-level top-level-mapping merge.
• Two opt-in builder stages, throughCst (per document) and throughCstStream (whole stream), composed CST-first: the String read terminals build a source-backed CST, apply the stream transform then the per-document transform, emit events, then run any event processors. This lets a pipeline edit structure with comments intact and decode/render the edited result in one pass.
• Matching top-level Yaml.decode/decodeAll/render/parse/parseAll over a CST, delegating to the default pipeline.
• README doctest and scaladoc for the new surface.

Notes

• Fast paths are unchanged: with no CST transform and no processor, Yaml.decode(String) and Yaml.pipeline.decode/render/parse(String) are byte-identical to before and construct no CST. This is pinned by a regression test.
• throughCst-staged render uses the trivia-aware CST renderer (not the event renderer) so comments on unedited nodes survive; render(stream) re-derives YamlCstRenderer.stream framing (document markers, ---/... separators). A stream transform clears the stream's originalSource so a structural edit (e.g. dropping a document) cannot render stale source.
• Yaml.render(doc) always emits canonically through the writer; Cst.Document.render returns the original source verbatim until edited. Both coexist and are documented.
• The CST merge for MergeTopLevelMappings is structural (skips non-mapping-rooted documents), which differs from the byte-level String merge; this is documented and tested.
• Verification: full focused YAML suites (286 tests), kyo-schema/doctest (66 blocks), and kyo-bench/compile all green; git diff --check clean.