[Basharkhan7776]

Closed #5621

JS-controlled lengths (0xFFFFFFFF) currently go through Vec::with_capacity in String.prototype.repeat, Array.prototype.join/sort/toLocaleString, JSON.stringify of arrays, CreateListFromArrayLike, and StringPad. That requests tens of gigabytes of metadata and aborts the process (rust_oom, exit 134) before any loop-iteration check.

This PR:

• Adds RuntimeLimits::max_allocation (bytes, default 1.5 GiB, same as the ArrayBuffer host hook).
• Adds Context::try_vec_with_capacity, which checks overflow, the cap, then try_reserve_exact.
• Routes the listed builtins (and TypedArray join / toLocaleString) through that helper.
• Cap exceeded → uncatchable RuntimeLimitError::Allocation. Allocator failure → RangeError.

Huge inputs such as "a".repeat(0xFFFFFFFF) and new Array(0xFFFFFFFF).join() now fail the cap without asking the OS for 100 GB.

Test plan

• Engine tests for the original abort triggers with the default cap
• Existing join / repeat / pad / sort tests still pass
• Lowering the cap rejects a modest repeat
• cargo clippy -p boa_engine -- -D warnings