Fix _str_to_int precision loss above 2^53 and add math_eval tests

[chenchenpan]

Summary

math_eval._str_to_int converted strings to int via float(x), which
silently loses precision for integers larger than 2^53 — the largest integer a
float64 can represent exactly. This resolves the existing TODO on that
function and adds the first test coverage for math_eval.py.

The bug

float('9007199254740993') (2^53 + 1) rounds to 9007199254740992.0, so
_str_to_int returned 9007199254740992 — off by one. Larger values drift
further (e.g. '12345678901234567890' -> 12345678901234567168).

This matters for MATH-style answer grading: _str_to_int feeds _normalize,
so two distinct large integers could normalize to the same string and be graded
as equal.

The fix

Parse integer-formatted strings directly with int(x) (arbitrary precision),
and fall back to float() only for non-integer formats:

def _str_to_int(x: str) -> int:
  x = x.replace(',', '')
  try:
    return int(x)
  except ValueError:
    return int(float(x))

'1.0' and '5e3' raise ValueError on int() and fall through to the float
path, so existing behavior for those is preserved.

Tests

Adds simply/utils/math_eval_test.py (absltest + parameterized, matching
the repo convention) — the first tests for this module. Covers answer
extraction, \boxed{}/\fbox{} parsing, normalization helpers, eval gating,
split_tuple, the >2^53 regression cases, and an end-to-end match test
(skipped when sympy is unavailable). 66 tests, all passing.

Notes

• No public API change; _str_to_int is module-private.
• No new dependencies.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.