The arrays of a tuple literal built at run time can be changed (#486)

[ASDAlexander77]

Two shapes of a tuple literal built at run time did not compile:

• A constant array inside it (let t = [x, [1]]; t[1].push(2)): the element kept its constant-array type, so push did not resolve. createTupleFromArrayLiteral now makes it an array of its own (a heap copy), as Arrays in an inferred tuple or record literal are heap copies (#479) #484 already did for a constant tuple holding an array.
• A const of it (const nt = [x, [2, [3, 4]]]; nt[1][1].push(5)): the const was folded into the CreateTuple value, so there was no reference to change the array through ("Can't get reference of the array"), and under rc nothing counted the arrays in it. Such a const now has storage when the tuple owns a block, as a let has and as a record literal's const has since rc/own: a record literal with a run-time field leaks the array in its fields #485.

Under own, const r = [i, [i, i]]; r[1].push(5) now gives the error the let form already gave ("'this value' takes a second reference") instead of "Can't get reference of the array".

New test 00tuple_runtime_arrays.ts (does not compile on main): let + push, const + pop, nested const + push, string-and-array tuple, a tuple passed to a [number, number[]] parameter, and a fresh array per loop pass.

Gate	Result
Windows full suite (Release)	3794/3794
Linux (WSL) full suite	3779/3779
DefaultLib suite, release + debug, compile + JIT	gc 159/159; rc, none 158/159 (weakref_basic is gc-only, as on main)
own corpus	no flips (459/615, 457/615 with --opt, same as main)
rc / own memory, 1M iterations (AOT)	let, const, nested, run-time values: flat at 4.4 MB

Closes #486

🤖 Generated with Claude Code