Decode a real descriptor set in the tests, on engine 3.4.19

[mgravell]

The decode tests write their payloads by hand, which keeps them legible and keeps them small. Nothing covered a payload with the depth, repetition and nesting a real one has.

descriptor.proto's own FileDescriptorSet is the obvious candidate. It is what protoc -o and protogen emit, so it is a likely thing for someone to drop into the decode view with a .bin they cannot identify, and it exercises groups, enums, extension ranges and deep nesting in realistic proportions — 13 KB, 1823 nodes.

Both halves come from protobuf-net.Reflection's embedded copy, so there is no binary fixture and no snapshot to drift: the test tracks whatever descriptor.proto the referenced package carries.

The schema is two lines. SchemaIndex walks every file in the set, imports included, so importing descriptor.proto names all 34 of its messages without restating any of them.

Three tests:

• every byte is consumed, and nothing is flagged, unknown or unnamed
• the root is inferred as FileDescriptorSet with no ties, when nothing says what the payload is
• the decode describes the very field it was read through — file reads as repeated FileDescriptorProto, and inside it, FileDescriptorSet.field[0] reads back as LABEL_REPEATED, TYPE_MESSAGE, .google.protobuf.FileDescriptorProto

One assertion is a DoesNotContain(..., e => e.IsError) rather than a null check: the stub schema imports something it never uses, and protobuf-net says so. The warning is correct, so the test allows warnings and not errors.

Engine 3.3.21 → 3.4.19

The payload needs a TypeModel. protobuf-net.Reflection brings only protobuf-net.Core, which has no concrete one, so the first pass took a test-only protobuf-net reference to reach RuntimeTypeModel.Default. 3.4.19 exposes FileDescriptorSet.Serializer instead, so that reference is gone and the payload is built with the model the package already carries.

That moves the engine itself, not just the test — every Generate on the site runs five releases further forward. Nothing in this repo covers codegen, so I checked it by hand rather than by assertion: C# and VB output is byte-identical between 3.3.21 and 3.4.19 across proto2 (groups, extensions, packed, defaults), proto3 (maps, oneofs, optional, well-known imports, streaming services) and edition 2023 (explicit presence, expanded repeated). The trimmed publish is still warning-clean, so the IL2104 audit in docs/trimming.md holds.

36 tests pass.