core: say how a number from the input or params that a 64-bit float can't hold is reported #89

#87 makes a check fail when the policy holds a number that a 64-bit float can't hold, because JavaScript reads 1e400 as Infinity and 1e-400 as 0, and the same check could pass there and fail with OPA. Numbers in the input aren't covered, and neither are numbers read from $$params with a ref.

OPA keeps them exactly, so a row's inputs shows {"name": "n", "value": 1e400}, and equals against 1e400 in the input compares exactly. An implementation in JavaScript would read the input as Infinity, write it as null in the report, and could compare it differently.

The same goes for a ref to $$params that reads 1e400. ergo doesn't control the input or the params, so failing the check might not be right. Options:

• fail any check that reads such a number, with its own cause
• leave it and say in REFERENCE.md that reports only match across implementations for inputs whose numbers fit a 64-bit float

🤖 Generated with Claude Code