fix(lexer): normalize CRLF in template cooked values

[ShanonJackson]

A template body's line terminator sequences are normalized in both the TRV and the TV, so a raw CRLF or a lone CR in the source becomes a single LF in the cooked value. push_template was cooking with normalization switched off, on the reasoning that a consumer could redo it from the raw text, so on a CRLF checkout every multi-line template cooked to bytes the grammar says it should not have. oxc_parser does the normalization itself in template_literal_carriage_return, so the two disagreed.

Redoing it afterwards is not possible, which is the part worth spelling out. Once escapes are decoded a CR in the cooked bytes is ambiguous: it may have come from a raw CRLF, which has to collapse, or from a \r escape, which has to survive, and a template of \r\n must cook to CR LF while any blanket pass over the cooked bytes would flatten it to LF. The decision has to be made on the raw text before escapes are decoded, which is inside cook, so this flips the existing const-generic on rather than adding machinery. Only push_template changes, since identifier atoms cannot contain a raw CR and a raw CR in a string literal is already an error. The new tests go through push_template rather than cook_decode, because the decoder was always correct and already had a passing test while the wiring was what was wrong. No measurable cost, and across both corpora exactly one file's output changes, nanoplotx_components.tsx, by one byte, the single CRLF it has inside a template collapsing to LF.