fix(db): parse SQL schema files regardless of line endings (#241)

[HugoFara]

Summary

Fixes #241 — fresh installs fail to boot with Internal Server Error - A database error occurred. and MySQL error 1064 while applying db/schema/baseline.sql.

Root cause

SqlFileParser::parseFile() split statements on ';' . PHP_EOL. PHP_EOL is "\n" on the (Linux) server, so the split looks for the literal ";\n". When baseline.sql has CRLF line endings (e.g. cloned on Windows with core.autocrlf=true and built locally), the real boundary is ";\r\n" and never matches. The whole file then collapses into a single multi-statement string, which mysqli_query() rejects after the first statement with error 1064.

The issue's error context shows the tell-tale symptom: two CREATE TABLE statements (_migrations + users) concatenated into one query, every line ending in \r\n.

Fix

parseFile() now reads the file whole, normalizes CRLF/CR → LF up front, then splits. Parsing is now independent of the file's origin OS, and CR-only files (which fgets() could not line-split at all) also work.

Tests

Added a data-provider regression test (testParseFileSplitsStatementsForAnyLineEnding) covering LF, CRLF, and CR. Verified end-to-end that a CRLF copy of the real baseline.sql now parses into 18 individual statements (previously 1 blob), with zero multi-CREATE TABLE statements.

./vendor/bin/phpunit tests/backend/Core            # 1163 passed, 22 skipped
./vendor/bin/psalm --threads=1 SqlFileParser.php   # No errors
./vendor/bin/phpcs --standard=PSR12 ...            # clean

Notes

• Likely warrants a 3.2.1 patch release since affected users can't self-heal a pre-built image.