descriptor: reject overlapping extension ranges

[fallintoplace]

What changed

• Reject overlapping extension ranges within the same message
• Check a sorted copy so declaration order stays unchanged
• Keep touching half-open ranges valid
• Add transactional FileDescriptorSet regression tests

Why

Hand-built descriptor sets could load overlapping extension ranges that protoc rejects.

Tests

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

[github-actions]

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

[iainmcgin]

[claude code]

The rule and the algorithm are right: protoc's check is pairwise half-open (range1.end > range2.start && range2.end > range1.start) with touching ranges legal, protobuf-go compares adjacent pairs on a sorted list, and comparing only adjacent pairs after sorting by (start, end) is sufficient given the early return. Transactional, nested-covered, no false positives against the in-tree descriptors (FeatureSet's 9995 to 9999 + 10000 are adjacent). A few things before merge:

1. Report both ranges, or mark the variant #[non_exhaustive]. OverlappingExtensionRange { message, start, end } names one range, and it is the sorted-later one rather than the declaration-later one (assert_rejected(&[(20, 30), (10, 25)], (20, 30)) bakes that in). protoc names both. PoolError is #[non_exhaustive] but its struct variants are not, so adding other_start/other_end after release is breaking — please add them now.
2. The rejection test builds a proto3 message with extension ranges. assert_rejected_without_mutating_pool hardcodes syntax: "proto3" (pool_e2e.rs:71), and protoc rejects extension ranges in proto3 outright, so the fixture is a descriptor protoc refuses for an unrelated reason and becomes a trap when buffa adds that check. Use assert_set_rejected_without_mutating_pool with syntax: "proto2", as descriptor: reject invalid extension range bounds #416 does. An overlap case at the MAX boundary ([(1, MAX+1), (MAX, MAX+1)]) would round out coverage.
3. Replace windows(2) + unreachable! with a running accumulator — CONTRIBUTING treats unreachable!/unwrap in library code the same way, and this removes the panic path:

   let mut previous_end = 0;
   for &(start, end) in &sorted_extension_ranges {
       if start < previous_end { return Err(...); }
       previous_end = end;
   }

4. Add (#417) to the fragment, and a doc line on the variant cross-referencing ReservedExtensionRange (overlap with a reserved range) so the two don't read as synonyms.

Sequencing: this will land after #416, at which point the .filter(|&(start, end)| start < end) is dead (the loop above returns Err on start >= end) — I'll drop it in the rebase if you haven't. #420 inserts at the same spot with its own sorted_extension_ranges; we'll resolve that when it lands. And as on the siblings, please drop the edit to the # Errors paragraphs on DescriptorPool::new / decode; one rewrite after the series.

[iainmcgin]

[claude code] No push since the review, so I've applied the items myself so this can ride 0.10.0: 07bdc4c merges main (now carrying #416's InvalidExtensionRange, which makes the start < end filter here unnecessary), makes OverlappingExtensionRange carry both ranges (start..end is the later declaration, other_start..other_end the earlier one, as protoc reports them), replaces the windows(2)/unreachable! loop with a sorted sweep, moves the rejection test onto the proto2 set-level helper with the MAX-boundary and a three-range case added, and cites (#417) in the fragment. CI approved and running.