extension: reject invalid field numbers

[fallintoplace]

What

• Reject invalid extension field numbers.

Why

• Invalid numbers can produce tags Buffa cannot decode.

Implementation

• Validate numbers in both extension constructors.
• Cover the range limits and reserved band.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[iainmcgin]

[claude code] Thanks for adding the check. Maintainer commits on top, after a merge of main:

• The constructors assert only that the number is nonzero and at most i32::MAX. An extension of a message with option message_set_wire_format = true can be numbered above 2^29 - 1 (protoc validates those ranges against the int32 maximum), buffa decodes such items, and Extension does not know the wire format of its extendee, so MAX_FIELD_NUMBER cannot be the ceiling here. The ceiling shares one constant with the MessageSet item decoder.
• The reserved band 19000 to 19999 is no longer rejected. That is a schema rule, which DescriptorPool applies when it loads a descriptor set; a number in the band encodes and decodes like any other.
• The constructors carry #[track_caller], each rule has its own panic message, and Extension::new has a compile_fail doctest for a const with number 0.
• The changelog entry is now under Breaking changes: the docs used to say that number 0 was accepted and inert, so a hand-written const with 0 compiled and now does not.
• The module # Panics section is the one list of accessors that check the extendee; the other docs and the guide refer to it, and the guide mentions the constructor panic.