fix(ci): tolerate CRLF checkouts in the api docs freshness test

[dubadub]

Summary

The docs_api_md_is_up_to_date test failed on the windows-latest CI runner (seen on #433's Test run): GitHub's Windows runners check files out with core.autocrlf=true, so docs/api.md arrives with CRLF line endings and no longer byte-matches the LF string api_docs_md::render() produces.

The fix normalizes CRLF to LF in the file content before comparing, so the test checks the docs' content rather than the checkout's line-ending convention.

Test plan

• Reproduced locally by converting docs/api.md to CRLF: test failed before the change, passes after.
• Restored the LF file: test still passes.
• cargo fmt --check, cargo clippy --all-targets, and cargo test all pass.

[claude]

Review

Small, well-scoped fix — looks correct.

Root cause check: confirmed this addresses a real gap. .github/workflows/test.yml's test-other-os job runs cargo test --verbose on windows-latest with default features, and server (which gates tests/api_docs_md_test.rs) is in the default feature set (Cargo.toml:14). On Windows, actions/checkout can check files out with CRLF line endings depending on core.autocrlf, so docs/api.md read via std::fs::read_to_string could contain \r\n while cookcli::web::api_docs_md::render() always builds its output with \n-only string literals (src/web/api_docs_md.rs). That mismatch would make the equality assertion fail spuriously on Windows even when the docs are actually in sync.

Why the fix is correctly scoped:

• Only actual (the file read from disk) is normalized, not expected (the in-memory render). That's the right asymmetry — expected is built entirely from \n literals in Rust source, so it can never contain \r\n regardless of platform.
• The regeneration path (UPDATE_API_DOCS=1, fs::write(&path, &expected)) is untouched and still writes LF-only content, so the file stays canonically LF in the repo — no risk of the fix causing CRLF to get committed.

Minor, non-blocking observations:

• actual.replace("\r\n", "\n") won't normalize a lone \r (old Mac-style line endings), but that's not a realistic scenario for a git-checked-out text file here, so not worth handling.
• No new test was added to cover the CRLF-handling behavior itself, but that's understandable — reproducing a Windows-style checkout in a unit test isn't practical, and this is effectively a CI-environment fix validated by the Windows leg of the matrix build.

Style/conventions: comment is concise and explains the why (matches CLAUDE.md's comment guidance), commit message follows the fix(ci): convention. No formatting, clippy, security, or performance concerns — this is a one-line logic change confined to a test file.

Nice fix — good catch tracing the Windows CI failure back to line-ending translation rather than a real docs/generator drift.