descriptor: reject fields in extension ranges

[fallintoplace]

What changed

• Rejects declared message fields whose numbers are inside extension ranges
• Uses ordered field numbers with a sorted temporary range copy
• Keeps the public extension range declaration order unchanged

Why

A hand-built or untrusted descriptor set could load a message field in a number reserved for extensions.

Tests

• cargo test --workspace --all-features
• cargo clippy -p buffa-descriptor --all-targets --all-features -- -D warnings
• cargo fmt --all --check

[github-actions]

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

[iainmcgin]

[claude code] With the sibling PRs going into 0.10.0 and no push here since 09-03, I've applied the review follow-ups myself (dafcfca): merged main; the field-vs-extension-range check now reuses the existing ReservedRanges index (binary search per field, no clone of the range list, and field_by_number keeps its original sort site); the variant is FieldNumberInExtensionRange to parallel ReservedMessageFieldNumber; the tests use the proto2 set-level helper (protoc forbids extension ranges in proto3) and add second-range / between-ranges cases; the fragment follows the house shape and cites (#420); main's wording kept for the DescriptorPool::new/decode error summaries. CI approved and running.