Return zero-copy views from large slice/substring/substr results

[lahma]

String.prototype.slice/substring/substr allocated a full string.Substring copy for every result. MemoryProbe attributed 89.9% + 9.2% of dromaeo-object-string''s 1.26 GB/op to exactly this.

What

The three methods now route through JsString.CreateSliced:

• whole-string results share the receiver / backing string outright (no copy, no wrapper for slice(0) on a JsString receiver);
• large results covering ≥ half of the source (and ≥ 512 chars) become SlicedString — an immutable lazy view (offset + length) over the backing string, nested beside ConcatenatedString. It materializes only on ToString() (cached), overrides indexer/Length/equality span-based (no materialization for length/charCodeAt/comparisons), hashes identically to the equivalent flat string, and — being immutable — never requires cloning, so it can be stored into bindings/properties without flattening;
• small or low-coverage results keep copying, so a short-lived view can never pin a much larger backing string (bounded retention: a view covers ≥ ½ of its source by construction).

TypeReference read JsString._value directly (the only such site outside JsString.cs) and now uses ToString().

Measurements (new StringSliceBenchmarks, same-window baselines, 128K char source)

Benchmark	Before	After	Alloc
SliceLargeDiscard	140.0 ms	1.51 ms (−98.9%)	1.14 GB → 394 KB
SubstringLargeDiscard	143.9 ms	1.89 ms (−98.7%)	1.14 GB → 1.0 MB
SliceThenRead	125.5 ms	1.62 ms	reads don''t materialize
SliceSmall (guard)	2.18 ms	2.19 ms	identical

EngineComparison dromaeo-object-string: wall-clock −53% (175.1 → 81.8 ms/iter), per-op allocations 1,272 → 136 MB (−89%) — the remaining MBs are the intentional retention-guard copies. base64/regexp guards unchanged.

Verification

• Jint.Tests 0 failures (net10.0 + net472), PublicInterface green
• Test262: 99,208 passed / 0 failed

🤖 Generated with Claude Code