prevent stored cal integer overflow

[anoobindisguise]

Summary

Bugfixes "stored calories cap instead of integer overflowing"

Purpose of change

Fixes #63727

Describe the solution

Simply limit max stored calories in the function that adjusts stored calories.
Should go along just fine with #60597.

Describe alternatives you've considered

Testing

Compiled and tested this by setting stored kcal to 2 million and guts kcal to 2 million and didn't see stored kcal exceed ~2.14 million after waiting over 24 hours repeatedly refreshing guts kcal to 2 million whenever it fell below 1 million kcal.

Additional context

[mqrause]

You need to check if stored_calories + ncal is safe to do without overflow. E.g. check if INT_MAX - stored_calories > ncal, otherwise just pass INT_MAX along.

A simple test case would be nice to have, too.

[anoobindisguise]

You need to check if...

shouldn't the std::abs do that anyways? if it overflows it will be -2147483647 which will correct it to a positive value, which is larger than the 2147000000 and thus min will reduce it to 2147000000. right?

[mqrause]

There's one more negative number because positive numbers start at 0, so you could get undefined behavior. You could also end up with less calories than before if you do it this way, which might not be the biggest concern, but it's weird behavior anyway.

[Qrox]

if it overflows it will be -2147483647

Signed overflow is actually undefined by the standard, so it's best to check if it would overflow here.

[irwiss]

I'll allow myself to voice an opinion as a normal contributor;
I feel this is over the top for the job it's supposed to be doing, in cata codebase there's tons of places where overflows may occur, in none of them we are doing even the trivial checks, it's also a non trivial issue for C++ newcomers to grasp. Some alternatives I can think of;
Use a uint32_t - makes it non-UB to overflow, keep same memory footprint but overflow will still kill the character, just at ~4b calories instead with the extra bit
Use a int64_t: give up 4 bytes per Character instance, but: over/underflow not practically reachable, calorie code doesn't seem to be on any hot paths, trivial for contributors
Make it a mix; widen to int64_t, do the addition/subtraction, check for overflow and clamp, cast back to int32 to store, still saves the 4 bytes per Character, which is overall worst of the bunch(imo) but still fairly trivial for contributors