csv-core: fix NFA read_record resumption after OutputFull

[maxtaran2010]

What this fixes

read_record_nfa initialised its local nout counter to
self.output_pos instead of 0. When the function is called a second
time for the same record (because the output buffer was too small and
OutputFull was returned), this caused two bugs:

Bug 1 — bytes written at the wrong offset.
The caller always passes &mut output[outlen..], so byte index 0 of the
received slice is the right place to start writing. Starting nout at
output_pos made the NFA write at output[output_pos], skipping
output_pos bytes and potentially writing out-of-bounds or corrupting
unrelated data.

Bug 2 — inflated returned nout.
The caller adds the returned nout to its own outlen accumulator.
Returning output_pos + bytes_written instead of bytes_written made
outlen grow too fast, so every subsequent call would pass a slice
starting too far along in the backing buffer.

The DFA counterpart (read_record_dfa) handles this correctly: it
starts nout at 0, computes field-end positions as
self.output_pos + nout, and updates output_pos as
self.output_pos + nout. This PR makes the NFA follow the same
pattern (three-line change).

How to reproduce

The bug is only reachable when the hidden nfa(true) builder option is
set, so existing tests never hit the OutputFull resume path. The added
test calls read_record twice for a single record using a 3-byte output
buffer for a 5-byte first field:

let input = b"hello,world\n";
let mut rdr = ReaderBuilder::new().nfa(true).build();

let (res1, nin1, nout1, _) = rdr.read_record(input, &mut [0u8; 3], ends);
// res1 == OutputFull, nout1 == 3, out[..3] == "hel"

let (res2, _, nout2, _) = rdr.read_record(&input[nin1..], &mut out2, ends);
// With the bug:  nout2 == 10, out2[..10] == "\0\0\0loworld" (wrong!)
// After the fix: nout2 == 7,  out2[..7]  == "loworld" (correct)

Scope

The NFA is a debug/testing path (#[doc(hidden)] builder option,
off by default). The default DFA path is unaffected.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.