Map DuckDB enums by label instead of underlying ordinal

[Copilot]

DuckDB.NET was writing enum values by casting their underlying numeric value directly into DuckDB’s enum storage. That only works when the CLR enum is dense and ordinal-aligned with the DuckDB enum definition; sparse enums and [Flags] enums could mis-map or throw unexpectedly.

• Appender enum mapping

  • Change enum writes to resolve the CLR enum member name and map it to the DuckDB enum dictionary label.
  • Remove the ordinal-based fallback so appends fail fast when labels do not match instead of silently writing the wrong enum.

• [Flags] handling

  • Reject [Flags] enums during append with an explicit InvalidOperationException.
  • This avoids unsupported composite values being coerced into a single DuckDB enum label.

• Reader alignment

  • Resolve DuckDB enum labels back to CLR enum members by name when reading typed enums.
  • Stop falling back to raw ordinals for typed enum materialization, which reintroduced the same sparse-enum assumption in reverse.

• Focused coverage

  • Add appender tests for:
    • non-consecutive enum values
    • [Flags] enum rejection
  • Keep existing dense-enum behavior covered by current tests.

Example of the supported sparse-enum case:

enum Mood : byte
{
    Happy = 1,
    Sad = 2,
    Neutral = 4
}

// DuckDB enum labels: 'Happy', 'Sad', 'Neutral'
row.AppendValue(Mood.Neutral); // now maps by label, not by underlying value 4