Import-DbaCsv - Fix Culture+DateTimeFormats to restore number parsing (issue #10338)

Two issues with the previous fix:

1. The derived format list included LongDatePattern strings (e.g.
   "dddd, d. MMMM yyyy HH:mm:ss") that contain locale-specific tokens
   (MMMM, dddd). The CsvDataReader library, when iterating these
   formats, throws on locale-specific patterns and immediately falls
   back to DateTime.Parse without a Culture set -- causing the import
   to fail entirely (null result).

2. Removing Culture from csvOptions broke the existing number-parsing
   behavior (comma as decimal separator for de-DE/de-CH etc.).

Fix: use only short purely-numeric patterns derived from
ShortDatePattern (e.g. "dd.MM.yyyy HH:mm:ss", "dd.MM.yyyy HH:mm",
"dd.MM.yyyy"). These never cause format exceptions, so the library
uses ParseExact cleanly and returns the correct day/month order.
Also restores Culture on csvOptions so number parsing continues to
work correctly.

(do Import-DbaCsv)

Co-authored-by: Andreas Jordan <andreasjordan@users.noreply.github.com>

Author: github-actions[bot]

public/Import-DbaCsv.ps1

@@ -604,18 +604,20 @@ function Import-DbaCsv {
         }
 
         # When Culture is specified but DateTimeFormats is not, derive unambiguous datetime format
-        # strings from the culture's DateTimeFormat patterns. This forces ParseExact (which respects
-        # field order) instead of Parse (which can swap day/month when both values are <= 12).
+        # strings from the culture's ShortDatePattern only (purely numeric patterns).
+        # This forces ParseExact (which respects field order) instead of Parse (which can swap
+        # day/month when both values are <= 12).
+        # NOTE: Only short patterns (no LongDatePattern with MMMM/dddd) are derived, because
+        # locale-specific month/day name tokens combined with InvariantCulture can cause the
+        # library's parser to throw and fall back to a broken Parse path.
         # See: https://github.com/dataplat/dbatools/issues/10338
         if ($PSBoundParameters.Culture -and -not $PSBoundParameters.DateTimeFormats) {
             $cultureObj = New-Object System.Globalization.CultureInfo($Culture)
             $dtf = $cultureObj.DateTimeFormat
             $effectiveDateTimeFormats = @(
                 "$($dtf.ShortDatePattern) $($dtf.LongTimePattern)",
                 "$($dtf.ShortDatePattern) $($dtf.ShortTimePattern)",
-                $dtf.ShortDatePattern,
-                "$($dtf.LongDatePattern) $($dtf.LongTimePattern)",
-                $dtf.LongDatePattern
+                $dtf.ShortDatePattern
             )
             Write-Message -Level Verbose -Message "Derived DateTimeFormats from Culture '$Culture': $($effectiveDateTimeFormats -join ', ')"
         } elseif ($PSBoundParameters.DateTimeFormats) {
@@ -1370,14 +1372,7 @@ WHERE c.object_id = OBJECT_ID(@tableName)
                         if ($effectiveDateTimeFormats) {
                             $csvOptions.DateTimeFormats = $effectiveDateTimeFormats
                         }
-                        # Only set Culture on csvOptions when the user explicitly provided DateTimeFormats
-                        # alongside Culture, OR when no DateTimeFormats derivation occurred.
-                        # When DateTimeFormats are auto-derived from Culture (issue #10338), do NOT set
-                        # Culture on csvOptions: the library bypasses DateTimeFormats when Culture is also
-                        # set, falling back to a broken DateTime.Parse path that ignores format order.
-                        # Omitting Culture here forces the library to use ParseExact with the derived
-                        # format strings, which correctly respects dd/MM vs MM/dd ordering.
-                        if ($PSBoundParameters.Culture -and $PSBoundParameters.DateTimeFormats) {
+                        if ($PSBoundParameters.Culture) {
                             $csvOptions.Culture = New-Object System.Globalization.CultureInfo($Culture)
                         }
                         if ($PSBoundParameters.StaticColumns) {