Native object writes, and the 64-bit binary arrays
This release is mostly speed and correctness rather than new coverage, and the numbers below are held honestly where the work does not move them. The loop compiler already turned object-heavy loops into a compact instruction stream; it now compiles them all the way to native machine code as well. Writing a field on an object walked out of a list (the everyday 'a[i].total = ...' shape that turns records into results in place) and reading or writing fields on a single hot object (a counter, an accumulator, a configuration object) both used to stop at the register-machine tier; they now reach the native tier, running about two and a half times faster on a warm object, proven equal to the interpreter across more than a hundred thousand fuzzed programs. Because the shapes already compiled, this is a speed-up, not new coverage, so the performance figure is held where it honestly is. Two more fixes round it out: a display:contents wrapper - an element that is meant to vanish and let its children stand in its place - now reports an empty box from getBoundingClientRect exactly as the reference browser does, where before it wrongly reported the union of its children, which can mislead layout-measuring page code; and the two 64-bit binary array types, BigInt64Array and BigUint64Array, are now present, so code that stores whole 64-bit integers (database ids, bitfields, hashes) runs instead of throwing on a missing class. That lifts the measured Web API surface from 519 to 521 of 577 - two members out of 577 is under half a percent and does not move the aspect, so that figure too stays where it honestly is. Every change carries a test and the engine gate holds at 6375 of 6375.