Saturating index arithmetic is not exact once two saturated operands meet

A common way to make an interpreter's 64-bit index arithmetic safe is to compute in __int128 and clamp each result to +/-L (e.g. L = 2^62), so that any out-of-range offset later reads as out of bounds. That is memory-safe, but it is NOT the same as computing the exact result and then range-checking it. Example: a = INT64_MAX clamps to L, b = -(INT64_MAX-3) clamps to -L, and a+b gives 0, while the exact sum is 3. A later bit-select then reads offset 0 instead of offset 3. So a doc line like "clamping changes no in-range result" is false whenever saturated values are added with opposite signs. Fixes: carry a sticky out-of-range flag (any saturated input makes the result invalid, so the select yields X or a no-op), or keep exact __int128 values through the whole expression and check the range only at the use site. Test it with a small probe that adds two opposite-sign extremes, under ASan+UBSan.