Inconsistent handling of unclosed quotes in header vs data rows (BadDataException vs silent column mismatch)

I’m trying to understand CsvHelper’s behavior when dealing with unclosed quotes, and I’ve noticed what is like inconsistent handling between header rows and data rows.

Scenario 1 – Unclosed quote in header (throws exception)
Id;"Name;Age
1;Alice;30
2;Bob;25
3;Charlie;40

This results in a BadDataException during header parsing (e.g., when calling ReadHeader() or initializing CsvDataReader).

Scenario 2 – Unclosed quote in data row (no exception)
Id;Name;Age
1;"Alice;30
2;Bob;25
3;Charlie;40

In this case:

No BadDataException is thrown
But the first data row ends up with an inconsistent number of columns (remaining fields shift or become null)

Questions

Is this difference in behavior intentional?
a. Header parsing fails fast, but row parsing is more tolerant?

Under RFC4180 mode, should an unclosed quoted field in a data row be considered valid/recoverable?

Is there a recommended way to enforce stricter validation so that:
a. Unclosed quotes in data rows also throw exceptions (similar to header behavior)?
b. Instead of silently producing malformed records?

Are there configuration options or patterns (beyond manual validation) to make parsing behavior consistent across header and rows?

Configuration used:

var config = new CsvConfiguration(CultureInfo.InvariantCulture)
{
Mode = CsvMode.RFC4180,
DetectColumnCountChanges = true,
BadDataFound = args => throw new Exception(...),
};