fast-xml-parser: Quadratic CPU consumption scanning unterminated stop-node tags

Root cause: a failed closing-> lookahead is neither cached nor bounded — n copies of <a with no later > means n scans over the remaining input, O(n²) work, before it finally throws.

Fix

1. Throw immediately in readStopNodeData() when readTagExp() returns undefined
2. Or break the loop on the first failed scan
3. Or find the next > once and reuse/bound that result
4. Add a test asserting near-linear scaling when payload size doubles

Proof of concept

Not benchmarked — static-analysis finding, confidence 0.5.

To confirm: configure stopNodes matching a root element. Build input as '<stop>' + '<a '.repeat(n). Time parse() until it throws Unexpected end of <tag>. Start around n=10,000 and double it — quadratic should show ~4x time per doubling, linear ~2x. Control: same input with a > present, or stopNodes unset.

Impact

CPU-exhaustion DoS in Node.js services parsing untrusted XML with stopNodes enabled. A ~100KB payload is estimated at ~10⁹ character operations (roughly a second or more of blocked event loop) — analytical estimate, not a benchmark. No confidentiality/integrity impact. CVSS 3.1: AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L (3.7, Low).