Engine: parse i64::MIN as a negative literal (-9223372036854775808)

[rrrodzilla]

Workstream: Engine · Part of #89 · surfaced by #108

Context

CEL has no negative integer literal token — -9223372036854775808 is unary minus applied to the literal 9223372036854775808. But 9223372036854775808 (2^63) does not fit in i64 (max 9223372036854775807), so the #107 lexer rejects it before negation can apply. This makes i64::MIN unrepresentable and costs a couple of basic/comparisons conformance tests.

Approach

Match cel-go / cel-spec: allow the integer-literal magnitude 9223372036854775808 to parse specifically when it is the operand of a unary minus, folding -(2^63) to i64::MIN. Options:

• Lexer/parser cooperation: when a unary - is immediately followed by an int literal whose magnitude is exactly 2^63, produce Int(i64::MIN) directly.
• Or carry an "out-of-range positive int literal" token that is only legal as a negation operand and errors otherwise.

Keep the error for a genuinely out-of-range positive literal (no leading -).

Acceptance

• -9223372036854775808 parses and evaluates to i64::MIN.
• The corresponding basic/comparisons conformance tests pass; raise MIN_PASS_BASELINE.

---

Dependencies: Refines #107 (parser). Soft.

[rrrodzilla]

Done in commit 8f54e4f (branch `dev`).

The lexer now emits a dedicated `IntMinMagnitude` token for exactly `2^63` (decimal or hex), and the parser folds a unary `-` immediately applied to it into `Int(i64::MIN)` rather than negating (which would overflow). A bare `2^63` with no leading minus remains an out-of-range error, and `i64::MAX` parses unchanged.

Conformance: 1018 → 1037. `integer_math` is now fully green (64/64); the fix also lifted `basic` (42/43) and `comparisons` (+13). `MIN_PASS_BASELINE` ratcheted to 1037. 98 tests green, clippy clean.