Consult the iterator's done flag before stepping it again

[lahma]

Four defects in array destructuring and the array iterator.

1. done was tracked but never consulted before stepping again

DestructuringPatternAssignmentExpression maintained a done flag and correctly suppressed the close when it was set, but nothing guarded the next step. Per §13.15.5.5 each element only steps If iteratorRecord.[[Done]] is false. Six call sites were unguarded — elision, Identifier, MemberExpression, nested pattern, rest element, AssignmentPattern — and one of them set done = true unconditionally before re-stepping.

[a, b, c] = iterableOf([]);   // "next,done,next,done,next,done" -> "next,done"

2. An elision terminated the whole pattern

The elision site did if (!ConsumeFromIterator(...)) break;, so every element after an elision was skipped once the iterator ran out:

var b; [, b = 5] = nonArrayIterable;   // b was undefined, must be 5

This one was not in the issue's description of the group at all.

3. A nested pattern received the iterator result object, not result.value

The nested-pattern branch assigned temp (the {value, done} object) where its three sibling branches all read CommonProperties.Value. This is a shipping bug beyond test262 — let [[a]] = someNonArrayIterable was broken, masked whenever the RHS is a real array because that takes an ArrayOperations fast path.

4. A replaced %ArrayIteratorPrototype%.next lost the iterated object

ArrayIteratorPrototype.Construct dropped its array and kind arguments and returned an iterator over the prototype when next was not pristine, so a replacement that delegates to the original got TypeError.

Now Construct always returns the real array iterator (that object is script-visible — it is what [][Symbol.iterator]() returns), and JsValue.TryGetIterator wraps it when next is not native. The check reads next off the instance, which also closes a related gap: §7.4.4 GetIterator step 3 reads next unconditionally, so an own next on an array-iterator instance was previously ignored.

Performance

Destructuring pays one perfectly-predicted branch per element on the iterator path, and it is saved work when taken; the real-array fast path is untouched. The Get(next) did not appear — it moved: Construct used to perform it on every call and no longer does, HasNativeNext performs it instead, so it is the same one read per iterator record. arr.values() called straight from script now performs zero reads where it used to perform one. Other iterator kinds pay one virtual call returning a constant, once per loop entry.

All 20 GetIterator call sites were checked; none casts to a concrete iterator type, and every other IteratorInstance subclass keeps the default.

Tests

Jint.Tests/Runtime/DestructuringIteratorProtocolTests.cs — 10 tests, 6 failing against unfixed code, asserting spec-exact next counts for 0/1/2/3-element iterables and full operation logs.

test262: 102,334 passed, 0 failed (+8; four files × two modes, verified in both sloppy and strict).

Frees Array/for_of_2.js, destructuring/order.js, destructuring/order-super.js, expressions/destructuring-array-done.js.

Two pre-existing gaps left alone and noted: for-of bypasses GetIterator when its RHS is already an IteratorInstance, and the array destructuring/spread fast paths identity-check @@iterator only, so a replaced %ArrayIteratorPrototype%.next is still skipped for a real array.

Refs #3021.