Return parse errors instead of panicking on out-of-range integers

[wackywendell]

Problem

Several parser paths convert grammar-matched integers with parse::<...>().unwrap(). Pest guarantees that the input has integer syntax, but not that the value fits the target Rust or protobuf integer type. Negative values parsed as unsigned integers and sufficiently large values therefore panic instead of returning a contextual parse error.

Examples include:

• function and URN anchors
• extension declaration anchors and integer extension values
• user-defined type and URN anchors and precision integers
• field references and integer literals

Inputs such as an oversized integer literal, #-1, or an anchor larger than u32::MAX should never unwind the parser.

Some paths already handle this correctly. Fetch limit and offset conversions map integer conversion failures into MessageParseError, and version components map them into ParseError::ValidationError.

Design consideration

ParsePair::parse_pair is currently infallible, which assumes the grammar has made construction of the Rust value infallible. That assumption does not hold for bounded numeric types: matching ASCII_DIGIT+ does not prove that a value fits u32, i32, or i64.

We should decide on a consistent fallible boundary for numeric pair conversion. Possible directions include making ParsePair fallible, adding a separate fallible pair-parsing trait, or introducing shared helpers/types for bounded numeric values. The goal is a coherent parser-wide approach rather than one-off workarounds for each anchor or literal.

Done when

• Malformed or out-of-range integer input returns a contextual parse error rather than panicking.
• Relevant anchor, field-reference, literal, precision, and extension-value paths no longer use unchecked integer conversion.
• Focused regression tests cover negative-to-unsigned conversion and values above the target integer range.