perf: prime the row split cache from the engine's multiline loop (#120)

[stevehansen]

Summary

• Engine's multiline continuation loop computes options.Splitter.Split per iteration to check for unterminated quotes, then discards the final split. The yielded row would lazily Split again on first field access — one redundant Split per multiline-enabled row.
• Extend IRowFactory<TRow>.Create with an IList<MemoryText>? rawSplit parameter; each factory assigns it to the row's rawSplitLine field. Engine threads the captured split from both the header-init pre-pass and the per-row multiline branch.
• Non-multiline paths pass null and the row's existing lazy split path is unchanged.

Resolves #120.

What changed

• Csv/CsvReader.Engine.cs: IRowFactory<TRow>.Create gains IList<MemoryText>? rawSplit parameter. All four factories prime the row's rawSplitLine when non-null. Both Enumerate and EnumerateAsync declare rawSplit at iteration scope and capture from both multiline branches.
• Csv/CsvReader.cs: rawSplitLine field on ReadLine, ReadLineSpan, ReadLineSpanOptimized moves from private to internal (sibling-nested factory structs don't get private access; sibling-class private access only applies to types nested within the field's owning type).
• Csv/CsvReader.FromMemory.cs: same for ReadLineFromMemory.
• The row classes themselves are already internal sealed; InternalsVisibleTo(\"Csv.Tests\") is in place from StringHelpers.cs. No public surface widened.

Perf delta

Path	Before	After
Multiline-enabled record, single physical line	1 Split in engine (check) + 1 Split on consumer's first field access	1 Split in engine, cache primed; no resplit
Multiline-enabled record, N physical lines	N+1 Splits in engine + 1 Split on consumer's first field access	N+1 Splits in engine, cache primed; no resplit
Non-multiline record	0 engine Splits + 1 lazy Split on first field access	unchanged

Test plan

• dotnet build clean on netstandard2.0, net8.0, net9.0
• dotnet test — 169/169 passing (excluding the pre-existing flaky Memory_AllocationComparison GC-ratio test)
• Existing multiline tests in Csv.Tests/EngineUnificationTests.cs, Csv.Tests/Tests.cs, and Csv.Tests/IssuesTests.cs continue to pass — they cover correctness; the perf change is unobservable without benchmarks (no dedicated regression test added)

🤖 Generated with Claude Code

[gemini-code-assist]

Code Review

This pull request optimizes the CSV reading process by allowing pre-split line data to be passed directly to row factories, reducing redundant splitting operations. The IRowFactory.Create method and its various implementations were updated to accept an optional rawSplit parameter, and internal fields were adjusted to store this data. Review feedback suggests further performance improvements by passing the expected column count as an initial capacity to the Split method in both synchronous and asynchronous enumeration paths to avoid unnecessary list reallocations.

[gemini-code-assist]

Since the engine already knows the expected column count from the headers array at this point, passing it as the initial capacity to the Split method can avoid unnecessary reallocations of the internal list buffer. This aligns with the performance goals of this pull request.

                    rawSplit = options.Splitter.Split(line, options, headers.Length);

[gemini-code-assist]

Similar to the synchronous Enumerate method, passing headers.Length as the initial capacity here will optimize the list allocation for the split results in the asynchronous path.

                    rawSplit = options.Splitter.Split(line, options, headers.Length);

[stevehansen]

Folded in @gemini-code-assist's capacity-hint suggestion in 76f983c — passes headers.Length to Splitter.Split in both the sync and async yield-loop re-splits.

[gemini-code-assist]

Thanks for the update, @stevehansen. That looks like a solid refinement to ensure the Splitter.Split calls are consistently optimized with the headers.Length hint across both sync and async paths. This should effectively minimize redundant work as intended.