Typed-array `sort`, `with` and `toReversed` are still silent no-ops (same cause as #8090)

[proggeramlug]

Summary

#8090 fixed fill, ranged fill, reverse and copyWithin on typed-array receivers by asking typed_array_receiver() before clean_arr_ptr rejects them. Its author noted that sort, with and toReversed are broken by the same cause and were deliberately left out of scope. Filing so they are not lost.

The mechanism (already established by #8090)

Codegen routes statically-typed typed-array receivers through the generic js_array_* helpers on purpose (#3148 / #654 — is_array_expr answers true for Int32Array &co.), on the contract that each helper re-dispatches on lookup_typed_array_kind.

clean_arr_ptr rejects those receivers, and must: since #7574 it returns null for every tracked non-GC_TYPE_ARRAY object, because a TypedArrayHeader's raw per-kind storage is not boxed-f64 ArrayHeader slots. Since the 2026-07-09 typed-array audit gave every typed array a real GC_TYPE_TYPED_ARRAY header, that rejection fires for all of them.

So any delegation written below the clean is unreachable, and the helper silently returns the receiver unmutated — no error, no diagnostic.

Expected shape of the fix

Same as #8090: call array::header::typed_array_receiver() ahead of the clean_arr_ptr funnel in each of the three helpers and delegate to the element-typed twin. typed_array_receiver already exists on main and strips the NaN-box tag itself without dereferencing.

Acceptance

A reproducer that is byte-exact against the pinned node oracle (v26.5.1, .node-version) and that demonstrably fails without the fix — #8090's did:

                 node          pre-fix perry
fill         9 9 3 4          1 2 3 4  (no-op)
reverse      4 3 2 1          1 2 3 4  (no-op)
copyWithin   3 4 3 4          1 2 3 4  (no-op)

Please include a plain-array control (it must be correct in both arms, proving the defect is typed-array-specific) and at least one non-Uint16Array element width. sort additionally needs a comparator case and the spec's default numeric ordering for typed arrays, which differs from Array.prototype.sort's string ordering — worth an explicit test, since that is a second way these can silently disagree with node.

Mirror #8090's negative coverage too: a test that clean_arr_ptr still rejects a typed-array receiver (keeping #7574 pinned), and one that plain-array mutators are unchanged by the new pre-check.

Refs #8090, #3148, #7574, #2879.