ci/docs: release-tag-only publishing, key collisions, source-generation metadata (9.0.0)

[CaffeinatedCoder]

Release-readiness items for 9.0.0 that came out of an independent review. Each point was checked against the code or measured before anything changed. Nothing in the packages' code changes: one CI guard, docs, and tests.

Publish only from a release tag (release.yml)

Before this change, a manual run of the release workflow from a branch with dry_run: false would have published. Two steps run only for tag refs, so that run would skip both:

• the check that the tag matches the version
• the GitHub release that permanently holds the SBOMs

Two repository settings already prevent this:

• the nuget environment only accepts deployments from v* tags
• the "Release tags are immutable" ruleset forbids deleting or moving a v* tag

But the YAML can't show either setting, and its own comment said the opposite.

What changed:

• publish now requires a v* tag ref as well.
• The comments describe those settings.
• The --skip-duplicate note now says to retry with "Re-run failed jobs". That pushes the same verified artifact again, whereas a fresh run rebuilds the packages, and with a floating SDK they need not match the ones already pushed.
• ReleaseWiringConventionTests.ThePublishJob_RunsOnlyForAReleaseTag reads the job-level condition. Restoring the previous condition makes it fail with the expected message.

Dictionary keys: two spellings of one key collide

Keys canonicalize, so {"[1,5]":"a","[1,6)":"b"} names the key [1,5] twice.

• Default options: System.Text.Json keeps the later value, silently. This is the same for Dictionary, IReadOnlyDictionary, ImmutableDictionary, variant keys and RangeSet keys.
• .NET 10's AllowDuplicateProperties = false: the collision is rejected with a JsonException, because the duplicate check runs on the parsed key.

docs/serialization.md#dictionary-keys now describes this and recommends that setting for keyed data where a dropped entry matters. JsonDictionaryKeyTests pins both behaviours.

Source-generation metadata for value sets

A source-generated context must list a value set's element type as well as the set.

• If it's left out: you get a NotSupportedException naming the element type, in both directions. That includes families that bring their own element converter.
• Pinned by SetSourceGenerationTests: the documented context working, and the missing-element error.
• NativeAOT smoke consumer: it now also runs the documented context for a primitive set, and a range serialized through object.
• Docs: they also note that serialization with default options (no context) is unavailable under Native AOT for every type, which is System.Text.Json's policy rather than this library's.

Test plan

• dotnet test: all passing, including the integration tests against a live PostgreSQL
• ./test/consumer-smoke-test.sh: passes, including both new AOT cases and no trim or AOT warnings
• CI

The new dictionary and source-generation tests pin existing behaviour; there's no source fix to revert for them. The workflow test was checked by restoring the old condition.

🤖 Generated with Claude Code