Property caches inline, sorts without calls, and an eval fix

After v0.0.25: the hostile bytecode-vm row back from 170 to 49 ms, a property cache's own-data hit taken inline in the interpreter, sorts and bitwise array callbacks without a call per element, and eval code that sees a replaced builtin.

The 15 October capture had the hostile bytecode-vm row at 3.13× Node's time, from 0.98× on 2 September. Since the strict call order, its helper-table loop needed nine spill slots where a compiled integer region may use eight, so the whole loop fell to the slowest tier; a region holding a computed-call splice may now spill up to twelve (fdb0222f), and the row runs in 49 ms instead of 170. In the interpreter, a property cache's own-data read and store are taken inline instead of through the full cache call (082d4a21, bdbec963), which moved the 18-row interpreter geomean against Bellard's QuickJS from 0.903× to 0.866×. A sort by the exact comparator (x, y) => x - y over Numbers computes each comparison without calling it in every unmetered profile (d9290e55; 200,000 Numbers in 18 ms instead of 90, interpreted), the fused map, filter and reduce kernels learned the bitwise operators (95fbe2dd), a compiled Map.get went from 24 to 14 ns (df840d75, 879d7cf8), and narrowing a double to an int and DataView member calls got cheaper (fc54b5a9, 786be5b4).

One wrong result came from the same embedding style as v0.0.25's reports: a program that silenced print with globalThis.print = function () {} still printed from eval, indirect eval, new Function and an embedder's later scripts, because code compiled after the program started seeded its slot with the original builtin. The slot now takes the builtin only while the global object still holds it, and the first write of a builtin through the global object keeps its non-enumerable attributes, as OrdinarySet does (b628f56d). a34c60e6 pins those writes on a non-extensible, a frozen and a sealed global against Node.