Fix MSVC clz/ctz impl

[zcyemi]

The previous implementation of ctz32 incorrectly used _BitScanForward,
which can cause division by zero exception(Crash) in js_atod when using like var x = 3.0.

Details:
in js_atod

radix_shift = ctz32(radix);
radix1 = radix >> radix_shift;

ctz32 return wrong value making radix1 to be 0, which propagates to mul_pow and causes l = (f + d - 1) / d with d = 0.
Then crash.

[MineRobber9000]

@nesbox Please merge, this causes a crash on using any decimal value in a JS cart in 1.2.

(NOTE: clz32/clz64 using XOR rather than subtract is fine, since we know that _BitScanReverse will always return in the range [0,31], and (31^x) == (31-x) for all x in that range, ditto _BitScanReverse64 and [0,63] and (63^x)==(63-x) respectively. I'm not sure it matters on modern CPUs but it could theoretically be a performance gain to leave those as is. Regardless of whether you use subtraction or XOR on the clz* functions, using it on ctz* is wrong.)

[nesbox]

Hmm, I'm not sure we need it here. It might be better to sync our submodule with the official QuickJS repo instead.
https://github.com/quickjs-ng/quickjs
and we have open issue for that nesbox/TIC-80#2917

[MineRobber9000]

That's a fork, not the official QuickJS repo; the official QuickJS repo is https://github.com/bellard/quickjs. (Not to say we couldn't use QuickJS-NG instead, but that's a different discussion than "just use the official upstream repo".)

If it were me in this position, I'd probably merge this fix and push out a hotfix for 1.2, since this bug makes TIC-80 crash on any JavaScript cart that uses a decimal number. Then, once the current version of TIC-80 is no longer crashing, we can have the discussion on whether we should update to the latest official QuickJS or swap to using QuickJS-NG instead.

(Of course, while you're merging this fix, you should rebase on the latest QuickJS 2026-06-04, which fixes the CVEs the TIC-80 issue mentioned.)