descriptor: reject duplicate oneof names

[fallintoplace]

What changed

• Reject duplicate oneof names within a message in DescriptorPool.
• Add a precise PoolError variant and display message.
• Add hand-built descriptor tests for rejection, transactional behavior, and distinct names.

Checks

• cargo test -p buffa-descriptor --features reflect --test pool_e2e
• cargo test -p buffa-descriptor --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]

This is correct and not redundant with the existing symbol table: on main only message and enum FQNs go through register_symbol, and symbol_file inserts oneof names without a collision check, so duplicate oneof names were accepted; protoc catches them because BuildOneof routes through AddSymbol. CI is green. Three small things and then it can go in:

• The fragment (.changes/unreleased/fixed-20260903-duplicate-oneof-names.yaml) should cite (#415) and name PoolError::DuplicateOneofName, matching the neighbouring 0.9.2 entries; please also rename the file to the fixed-YYYYMMDD-HHMMSS.yaml shape changie new produces (changie ignores the name, but it keeps the directory sortable).
• In duplicate_oneof_names_are_rejected_transactionally give each oneof a member field. protoc separately rejects an empty oneof ("Oneof must have at least one field"), so as written the descriptor is invalid for two reasons and the test stops isolating this rule the day buffa adds that check.
• BTreeSet<&str> over o.name.as_deref().unwrap_or("") avoids the per-oneof String clone on the happy path.

Not for this PR, noting for completeness: protoc's per-message symbol scope also rejects a oneof whose name collides with a field or nested type in the same message; buffa still accepts that. If you pick it up later, keep it separate from the existing field_names map, which also carries json_names (protoc's json-name conflict check is field-only, so merging would falsely reject oneof fooBar + int32 foo_bar).

Please drop this PR's edit to the # Errors paragraphs on DescriptorPool::new / decode — eight open PRs rewrite that same sentence, so we'll replace it once with a short summary pointing at the PoolError variants after the series lands.

[iainmcgin]

[claude code] No push since the review, so I've applied the items myself so this can ride 0.10.0: f34688c merges main, borrows the oneof names (BTreeSet<&str>) instead of cloning each, gives the test's oneofs member fields so the descriptor is invalid for one reason only, and replaces the fragment with a timestamped one citing (#415) and the variant; main's wording kept for the error-summary paragraphs. The oneof-vs-field-name collision noted above stays a follow-up. CI approved and running.