GeezerVison

Summary

Normalize CRLF and lone CR before parser warnings and compilation, including physical newlines inside string literals. This follows CPython 3.15's _PyTokenizer_translate_newlines / _PyTokenizer_FromUTF8 ordering.

This is an independent alternative to close #9762, not stacked on it. The original change fixes literal values but runs after VM parser warnings and leaves diagnostics reading the untranslated input.

• Share one universal-newline translator between source decoding, compiler entry points, symbol-table compilation, and syntax diagnostics.
• Translate before VM parser warning collection. Keep diagnostic line lookup consistent with the translated parser source.
• Borrow CR-free input; otherwise use a single output allocation instead of chained full-string replacements.
• Preserve the caller's original source bytes in compile audit events.
• Cover CR/CRLF combinations, ordinary/raw/bytes/f-/t-string literals, docstrings, explicit escape preservation, AST compilation, warnings, error text consistency and audit input.

Verification

• CPython 3.15.1 and RustPython builtin_compile.py / builtin_compile_module.py: pytest 4 passed.
• RustPython test_compile: passed (187 tests run, 51 skipped).
• CLI -c physical-CR literal checks: passed.
• Full workspace Rust tests, separate CAPI tests, workspace/CAPI clippy with -D warnings: passed.
• Shared normalizer tests and pre-commit hooks: passed.

This does not claim full parser diagnostic parity: existing LF-input differences in trailing newlines in SyntaxError.text and warning-as-error precedence for invalid source also remain for CR input. This patch makes the newline forms consistent; it does not hide those independent differences.

AI assistance: OpenAI Codex.