fix: differentiate explicitly empty string delimiter from "no delimiter"

[rmja]

What kind of change does this PR introduce?

Fixes #2294.

What is the new behavior?

QueryFormData is default when no [Query] attribute is present, so Delimiter is null in that case — the IsNullOrEmpty guard was there for the absent case, but it swallows "" along with it. Now data.Delimiter ?? DefaultNestingDelimiter, with Delimiter retyped to string? so the absent case is expressed as null rather than leaning on emptiness. Three call sites: object query, CollectionFormat.Indexed collections, and path-residual queries.

What is the current behavior?

The source generated and reflection client generates different queries for empty string delimiters.

What might this PR break?

There should be none, as this pr fixes a mismatch between the reflection based client generation and source generated client.

Checklist

• I have read the Contribute guide
• Tests have been added or updated (for bug fixes / features)
• Docs have been added or updated (for bug fixes / features)
• Changes target the main branch
• PR title follows Conventional Commits

Additional information

[rmja]

Worth flagging since it's a judgement call and not purely mechanical: this makes the fix touch a test that was written deliberately. The argument is parity — for the Indexed path the generator was the only one inserting the dot, and TryBuildIndexedCollectionModel requires data.CollectionFormatValue.HasValue, which requires a [Query] attribute, which always carries a non-null Delimiter. So the ?? DefaultNestingDelimiter fallback on that path is now purely defensive and unreachable in practice.

[rmja]

Great. It seems CI is finally happy. Let me know what you think!