[Bug] Validate DAPO labels as exact integers without float coercion

[morluto]

Current limitation

The DAPO scorer canonicalizes ground-truth labels with int(float(gt)). This can change the value being compared:

• "0.5" becomes "0", so a prediction of 0 is incorrectly accepted.
• Integers beyond binary64's exact range can be rounded before comparison. For example, 9007199254740993 may no longer match itself.

DAPO-Math-17K defines its labels as integers, so the scorer should validate that contract rather than truncate or round labels.

Expected behavior

Malformed, non-finite, and non-integral labels should be rejected with a contextual error. Valid integral decimal and exponent spellings should be canonicalized without losing large-integer precision.

Related pull request

• fix: validate DAPO integer labels without float coercion #2203 — fix: validate DAPO integer labels without float coercion #2203