Fix Object.assign with array target losing length update (#2126)

[Finomosec]

Summary

Object.assign([], src) returned an empty array instead of a copy of src's
enumerable own properties. The integer-keyed property writes went through
AbstractEcmaObjectOperations.put → ScriptableObject.putOwnProperty →
putImpl, which bypasses NativeArray.put(int) and so the array's length
was never updated. The slots got stored but stayed invisible to iteration
and serialization.

Reproducer (failing before this PR):

const arr = ['bla', 'blubb'];
const clone = Object.assign([], arr);
JSON.stringify(clone);      // → "[]"   (expected: ["bla","blubb"])
clone.length;               // →  0     (expected: 2)

Fix

Short-circuit to targetObj.put(...) in NativeObject.js_assign when the
target is a NativeArray, so the array's own put-path (which maintains
length) is used. Same special-case for the String-key path, since numeric
string keys like "0", "1" are also indexed properties for arrays.

The non-array code path stays exactly as before.

Tests

New ObjectAssignArrayTargetTest (32 cases) covering:

• the original reproducer, length update, indexed access
• pre-filled targets, sparse sources (holes skipped), multiple sources
• mix with push / spread / forEach / map / reduce / splice
• pre-sized arrays via new Array(n) (length must not shrink)
• nested Object.assign chains, 100-entry volume test
• object-target baseline (must remain unchanged)
• spread, basic array/object destructuring (the supported subset)

All tests run in both interpreter and compiled mode via
Utils.assertWithAllModes_ES6.

Context

Refs #2126.

[Finomosec]

For reviewer context: this PR implements exactly the approach @aardvark179 outlined in #2126 (comment):

We can't simply subclass putOwnProperty for NativeArray because that causes infinite recursion due to the way things are currently written. I think the only short term fix for this bug is to special case things for arrays.

Scope is intentionally narrow — only the NativeArray target case in js_assign. Other exotic object types that may share the same problem (raised earlier by @aardvark179 in the same issue) are left for the broader put/[[Set]] refactor that's planned alongside the scope split for 2.0.

Also pushed an update that adds the exact reproducer from the original issue (Object.assign([4,5,7], [1,2,4]) → [1,2,4]) as its own test case, so the regression is documented verbatim.

[rbri]

@Finomosec pleasr run

./gradlew spotlessApply

to correct the formatting

[gbrail]

Looks great, going to give the others a minute to take a look, thanks!

[gbrail]

I rebased the tests and ran them locally, and no test262 tests failed, but sadly no new tests passed either. I still think we should merge this though!

[rbri]

@gbrail did something similar, same result.

[gbrail]

Still a good fix though -- thanks!