fix(parser): avoid stack overflow on large tag expressions (#817)

[Kirylka]

Problem

tagExpWithClosingIndex (introduced in 5.5.11) accumulates every scanned char code into a chars array and returns the result via String.fromCharCode(...chars). When a tag expression is large enough, the spread exceeds V8's per-call argument budget and surfaces as:

RangeError: Maximum call stack size exceeded
    at fast-xml-parser/lib/fxp.cjs:1:xxxxx
    at st (...)
    at parseXml (...)
    at parse (...)

Shallow 4-frame trace (not recursion-driven). Bisect pins the regression to 5.5.11; every release since (5.5.11 / 5.5.12 / 5.6.0) still reproduces it. Affects real-world XML like 12MB Adobe AE .aepx files and 46MB XHTML ESEF reports (#817).

Fix

Two-phase approach inside tagExpWithClosingIndex:

1. Single forward scan locates the close-delimiter position and tracks quote boundaries. It only records whether any \t was seen inside a quoted attribute value — no per-char string building.
2. Fast path (no tab inside a quoted attr): xmlData.substring(i, close).replace(/\t/g, ' '). This is the common case for real-world XML — zero per-char work.
3. Rare path (tab inside a quoted attr): walk the extracted substring once, preserving tabs inside quotes and normalising tabs outside quotes to spaces. Matches 5.5.10 semantics exactly.

Keeps the 5.5.11 perf improvements (charCodeAt comparisons, precomputed close codes, cached len).

Verification

Correctness

• All 310 existing specs pass
• Two new regression tests in spec/large_spec.js:
  • 200k-char attribute value — fails on unpatched 5.5.11+, passes after
  • Tab preserved inside quoted attribute — guards the 5.5.10 semantic
• A 24-case byte-equality battery (edge cases: tabs inside/outside/adjacent quotes, single vs double quotes, surrogate pairs, long attrs, PI with tabs, entities, boolean attrs, etc.) — every case produces output byte-identical to 5.5.10
• Verified against the 12MB .aepx from Error: RangeError: Maximum call stack size exceeded #817 — output SHA-256 identical to 5.5.10

Performance (Node 22, median over many iterations)

input	pure 5.5.10	this PR	delta
small XML	0.01ms	0.01ms	~0
medium XML (~8K)	0.50ms	0.41ms	−18%
wide attr (~5K chars)	0.05ms	0.03ms	−37%
very wide attr (~200k chars)	2.88ms	1.27ms	−56%
12MB .aepx (#817 repro)	324ms	289ms	−11%

Closes #817

[amitguptagwl]

Thanks for your effort and time. Since the PR contains browser bundle which are not accepted in PR. I've updated desire method. Please check current code on github. This would be released tomorrow.

[Kirylka]

Quick heads-up on the commit that landed on master (e174168): it's close to my first pass (substring + bulk replace(/\t/g, ' ')) and does fix the stack overflow, but it drops two things that were in later commits on this branch:

1. Tab preservation inside quoted attribute values. v5.5.10 preserved \t literally when it appeared inside "..." — only tabs outside quoted attrs were converted. The committed version replaces every tab in the tag expression, so <item a="x\ty"/> now comes back as "x y" instead of "x\ty". Arguably more XML 1.0 §3.3.3 compliant for CDATA attrs, but a silent behavior change for anyone upgrading from 5.5.10.

2. Regression tests. This failure mode (a perf refactor introducing the spread bomb in the tag-expression reader) only came in during 5.5.11 itself — without tests the same shape of bug could slip back on the next pass.

If useful, the two small specs on this branch cover both cases (the 200k-char tag-expression test guarding #817, and the tab-in-quoted-attr semantic). Happy to open a separate tiny PR with just those, or you can lift them directly.

Either way, thanks for the quick turnaround.

[amitguptagwl]

I noticed that if we build an array in tagExpWithClosingIndex like this [tagname, true, booleanAttr, true, attr, val] then it will simplify the logic of boolean attributes and raw attributes methods too. But this will need some time. So I'l reverting my changes to release rest of the changes and then we can take this change.