Fix #751, #753, #754: typed-array index IL-verify, string rest element, assignment destructuring

[nickna]

Completes three issues from the #685 array-destructuring cluster.

#754 — Array/object assignment destructuring (without declaration)

[a, b] = rhs and ({ a, b } = rhs) (assigning to existing l-values) now parse and run in both interpreter and compiled mode.

• New Expr.DestructuringAssign carries the parser-lowered assignment statements (reusing the Array destructuring desugars to index access, so it fails over non-indexable iterables (generators, Set, Map) #685 __arrayDestructure iterator path and __objectRest) plus the original rhs as the result value. Every backend lowers it identically — run the statements, yield the result — so async/generator contexts work for free (each statement goes through the normal EmitStatement/ExecuteStatementAsync path).
• Supported: variables, member/index/private targets, leaf & member defaults, holes, rest (binds a real Array), nested patterns (no default), object shorthand/rename/rest/computed-key/string-key, iterator sources (Set/Map/generators), expression position, chaining ([a,b]=[c,d]=x), and await in the rhs.
• Spec semantics verified: the rhs is evaluated once, targets are written left-to-right after their receivers are evaluated, and the expression evaluates to the original rhs (([a,b]="hi") === "hi").

#753 — String rest element binds a substring instead of an array

const [a, ...rest] = "hello" now binds rest = ["e","l","l","o"] (a fresh Array), matching ECMA-262, instead of the substring "ello". String is dropped from the index-addressable pass-through in the type checker, interpreter (NormalizeArrayDestructureSource), and compiled ArrayDestructureSource/handler, so it materializes through the iterator path. Non-rest character bindings are byte-for-byte unchanged.

#751 — Numeric Set/Map spread/destructure fails --verify

Root cause was broader than the title: every typed-array (number[]/boolean[]) index read/write emitted IL that fails ILVerify. The typed List<T> fast path left a native double/bool on the stack where the sibling $Array/List<object>/fallback paths — and every consumer, which reads the clobbered StackType=Unknown — expected an object ref (StackUnexpected {Found=Double, Expected=ref 'object'}). It only ran because the typed branch is dead code for an $Array-backed value. The fast path now boxes its result at all four sites (GetIndex/SetIndex × hoisted/non-hoisted), converging every branch on object. The fix follows this codebase's established "box a typed value before a generic object slot" pattern (#279/#344/#367). Behavior- and performance-neutral: the unboxed value was never actually consumed unboxed (the consumer always required a boxed object). The numeric Set/Map spread/destructure repro inherits the fix.

Tests

• DestructuringTests: string-rest (Array destructuring: string rest element binds a substring instead of an array #753) and assignment-destructuring (Parser: array/object assignment destructuring (without declaration) is rejected #754) cases — basics, swap, defaults/holes/rest, member targets, object rename/rest/default, iterator source, expression position, chaining — all over both execution modes.
• ILVerificationTests: typed-array index read+write (number & boolean, typed- and object-backed) and the numeric-Set spread/destructure repro (Compiled: spreading/destructuring a numeric Set/Map emits IL that fails ILVerify #751), each asserting clean IL verification + interpreter parity.
• Full suite green (13206 passing; the lone intermittent failure is a pre-existing async-gen timing flake, reproduces clean on re-run and is outside the touched areas).

Conformance

The TSConformance subset (assignmentCompatibility + conditional) is unrelated to destructuring/parsing. Test262 runs .js with type-checking off; the runtime/parser changes here were validated via the spec-semantics checks above and the both-mode unit tests rather than the heavy, uninitialized-submodule + stale-baseline Test262 isolation.

Follow-ups filed

#779 (nested pattern with a default in assignment destructuring), #780 ({a = 5} object-shorthand-default parse), #781 (typed-array rest → Array, interpreter), #782 (new Uint8Array([...]) crashes compiled — pre-existing), #783 (mixed nested array-literal tuple inference — pre-existing, affects declaration too), #784 (destructuring default applies on null via ?? instead of undefined-only — pre-existing).