Parent: #496 Related: #537, #549
Problem
normalizeTemplateRaw correctly maps CRLF and lone CR to LF, but the first CR switches the complete template token to byte-at-a-time ArrayListUnmanaged growth in the parser arena. Allocation request count and retained capacity therefore depend on the raw length even though the normalized output size is knowable before allocation. Both untagged cooked values and tagged template raw/cooked arrays consume this path.
Scope
- Add 1K/2K/4K mixed CRLF/lone-CR template parser rows plus a tagged 4K control, validating every complete normalized value.
- Count the exact normalized length before allocation, allocate once, and fill once.
- Preserve zero-allocation source borrowing when no CR is present.
- Preserve TRV rules, line continuations, substitution boundaries, tagged raw/cooked values, LS/PS bytes, invalid escapes, source lifetimes, and diagnostic behavior.
No-workaround rules
- No worst-case allocation, hidden scratch buffer, source rewriting before the timed parse boundary, CR-only special-case that mishandles CRLF, reduced tagged-template validation, or deferred syntax errors.
Acceptance
- Any raw template token requiring CR normalization uses one exact output allocation with no growth/transfer; CR-free templates remain source-backed.
- Mixed CRLF/lone-CR, leading/trailing terminators, escaped line continuations, substitutions, tagged raw/cooked, LS/PS, and deterministic OOM paths have direct tests.
- Benchmark validation independently checks every normalized element and records 1K/2K/4K allocation growth plus a tagged control.
- Focused frontend, parser/lexer, TSan, full units, and exact template/tagged-template test262 comparisons pass.
- Exact-parent evidence records wall, hardware counters, allocation requests/bytes, RSS, checksums, and dispersion without moving source construction or parsing outside the timed boundary.