fix(parser): return an error for numeric literals above i64::MAX

What does this MR do and why?

fix(parser): return an error for numeric literals above i64::MAX

number() and relative_date_inner() unwrapped parse::<i64>(), so a numeric literal above i64::MAX panicked instead of returning a compile error. In the WASM build that surfaces as an unhandled runtime error rather than {success: false, output: "Error: …"}.

Both sites now return nom::Err::Failure with a new NumberOutOfRange kind, mirroring UnterminatedString, so alt reports the number rather than backtracking into a generic "unexpected token". In relative_date_inner the check stays after the unit letter is matched, since relative_date runs before number in non_array_value: a bare digit run must still backtrack and fail in number() with its own kind (pinned by test_overflowing_literal_reaches_number_not_relative_date).

Tests assert the Failure and its kind through a new test_parser_failure helper; test_parser_error accepts any Err and would pass on the exact behaviour this rules out. The compile-level pair uses weight =: i64::MAX compiles, one digit more errors. weight only supports =, so a > control case would fail at analysis for the operator, not the number.

Negative literals and the i32 GraphQL Int boundary are out of scope, as agreed on the issue.

Closes #174 (closed)

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. On main, copy tests/parser_tests.rs from this branch and run cargo test --test parser_tests number. The two test_number_above_i64_max_* cases die with:

   thread 'test_number_above_i64_max_errors' panicked at src/parser/literals.rs:29:44:
   called `Result::unwrap()` on an `Err` value: ParseIntError { kind: PosOverflow }

2. On this branch, cargo test. All pass, including the new cases in literals.rs, special.rs, and parser_tests.rs.

Side Note

Also out of scope: relative dates with an in-range quantity still panic later, in the transformer's date arithmetic (calculate_days / start_of_day). created > 3000000000d and created > 15250284452w panic, while the same magnitude with m or y returns a clean error, via months_to_days. All four units additionally panic at i64 extremes on unchecked arithmetic. Pre-existing on main, and outside the parser's bound since these are valid i64 values.