Das ist ein bisschen wacklig, wenn's auch auf Windows "richtig" laufen soll.
Text::CSV ist leider ein bisschen schwammig in der Beschreibung, wie das bei der Ausgabe ablaufen soll. Hier das Verhalten der Funktion csv:

• Wenn man da eol nicht angibt, schreibt er \r\n, auf allen Plattformen. Das ist auch RFC4180-konform (da steht CRLF).
• Wenn man eol => "\n" (oder eol = $/) angibt, dann schreibt er "\n" auf Linux und "\r\n" auf Windows. Bei Windows ist eben per Default der :crlf-Layer aktiv, und anscheinend tut Text::CSV nichts, um den abzuschalten.
• Wenn man eol => "\r\n" angibt, dann schreibt er "\r\n" auf Linux und "\r\r\n" auf Windows. Das ist eher unerwünscht.

Die solide Variante wäre also, eol nicht anzugeben und also auch nicht im App::DBBrowser anzubieten - das schlage ich auch vor. Dann steht CRLF in den CSV-Dateien, das ist RFC-konform ud die handelsüblichen CSV-Tools sollten damit klarkommen.

Etwas Kleingedrucktes:
$/ ist der $INPUT_LINE_SEPARATOR und der ist auf Windows und Linux gleich "\n". Der Unterschied entsteht erst bei den I/O-Layern. Ausgabe ist aber nicht Input, den als Wert zu verwenden wäre schräg. Es gibt auch $\, den $OUTPUT_LINE_SEPARATOR. Der ist normalerweise undef, sein Inhalt wird an jede print-Ausgabe drangehängt. Damit ist das auch ungeeignet, um ein überzähliges \r von Text::CSV zu eliminieren.