check from_chars result for integer literals in script parser

[aysha-afrah26]

The script parser turns each integer literal into an int64_t with std::from_chars but drops the result, so the one failure the tokenizer can still hand it, result_out_of_range, goes unnoticed. On overflow from_chars leaves the output untouched, which means a literal that does not fit in 64 bits is silently read as 0 instead of being reported. I ran into this with a bitmask: 0xFFFFFFFFFFFFFFFF in a script expression evaluates to 0 rather than all bits set, and 0x8000000000000000 or a long decimal like 99999999999999999999999 behave the same way. These expressions come straight from the XML (Script, preconditions, postconditions) and are compiled at tree build time through ParseScript/ValidateScript, so a tree that looks valid quietly computes with the wrong constant. The fix captures the from_chars result and raises a normal parse error when the literal is out of range, matching how the real-number branch already rejects bad input. Valid literals, including the int64 boundary values, are unchanged, and I added a regression test that fails before the change and passes after.