Fix memmove sizes in array shift, unshift and splice

[ASDAlexander77]

Problem

Two bugs in the element moves of the array mutation lowerings (LowerToLLVM.cpp):

1. MemoryMoveOpLowering scaled the count by a pointer's size. It multiplied the count by the size of the source operand's type, but the operands are plain pointers. For elements wider than 8 bytes, shift, unshift and splice moved only part of each element:

   let s: [number, string][] = [[1, "a"], [2, "b"], [3, "c"]];
   s.shift();   // left [2,"b"], [2,"b"] instead of [2,"b"], [3,"c"]

   unshift on such an array segfaulted, even under -mm=gc.
2. ArrayUnshiftOpLowering moved the new element count instead of the old one, writing items elements past the end of the reallocated block. Under -mm=gc and -mm=none nothing noticed. Under -mm=rc the debug CRT heap caught it on free, which is why test-jit-rc-owned-array-ops and test-compile-rc-corpus-00owned-array-ops fail on debug builds (CI builds Release, where the heap doesn't check).

Fix

• MemoryMoveOp's count is now in bytes, like MemoryCopyOp's.
• All four callers pass element count × element size: unshift and shift, plus both branches of splice.
• unshift moves the old count.

Tests

• New 00array_move_wide_elements.ts (compile, jit, rc/none corpus): shift, unshift, and splice in both directions (growing and shrinking) on an array of tuples. It fails on the previous compiler with assertion failed: shift second.
• 00owned_array_ops passes under gc, rc and none.
• Full Windows debug suite: 2730/2733. The 3 remaining failures (gc-shared-auto, gc-defaultlib-collector ×2) are an unrelated CRT report-hook breakpoint and a default-library CRT flag, fixed separately.

🤖 Generated with Claude Code