Proposed fix: normalize Windows SQL migration line endings

Summary

SQLx hashes the exact migration SQL bytes. Official Windows Codex builds have embedded CRLF migration files, while a Windows source checkout with core.autocrlf=false embeds LF files. A locally built binary can therefore reject a healthy database created by the official Windows package with:

migration 1 was previously applied but has been modified

The proposed fix canonicalizes runtime migrations to CRLF on Windows before SQLx executes or validates them. This makes Windows builds compatible with official Windows databases regardless of the developer checkout's line-ending configuration. It applies centrally to state, logs, goals, memories, and thread-history runtime migrators.

This addresses the native-Windows side of the migration checksum failures discussed in #23841, #23848, and #23863. Those reports also involve WSL processes opening the same Windows database; accepting both legacy LF and CRLF histories cross-platform may be a preferable broader policy. The attached patch is deliberately limited to compatibility with already-released Windows databases.

Evidence

For migration 1:

• LF SHA-384: 627EF19164C9BB298A0CD99945981C9B7BDA3D9E6CF12EB35145E3B1D3BF7CF8740F0DBAA0B475185FC2993397078049
• CRLF SHA-384: 54BBD6F47905A4E4C674034575963D82DA7B534E66E9A37A81EC2AFB6A4B56CE6DE9B3ECF3032796A800F650239847D4

The CRLF hash exactly matched the live database. Read-only inspection and byte-level hashing confirmed that all 40 applied state migrations matched their CRLF forms. The database was not corrupt, and no migration-table rows were edited.

Proposed patch

• Downloadable patch
• Commit
• Branch comparison against current main
• Branch: JoNil-Botta:fix/windows-migration-crlf-main

Validation

• just test -p codex-state: 154 passed
• focused CRLF-release/LF-checkout compatibility test passed
• just fix -p codex-state
• just fmt
• a corrected release build opened a copied database and the live database successfully
• codex doctor --summary --no-color --ascii: state databases healthy, 0 failures