ISet<string> list values expand in hash order while pair-sets are canonicalized

[brenpike]

Found during a repeat repo-wide read-only correctness sweep (2026-08-23).

Severity: info. Current behavior may well be the right choice; the issue is that it is undocumented and inconsistent with the sibling case.

Problem

The expander canonicalizes ISet<KeyValuePair<...>> for determinism, but leaves IEnumerable<string> — including HashSet<string> — in enumeration order (src/Chatter.Rest.UriTemplates/UriTemplateExpander.cs:53-69).

So {?tags*} with tags = new HashSet<string>{"b","a"} expands in hash order, which can differ across processes. That is exactly the nondeterminism the associative-array ordering contract was built to eliminate (src/Chatter.Rest.UriTemplates/UriTemplateExpander.cs:229-318, and the ordering section of docs/usage.md), and it matters for the same reasons: cache keys and signed URLs.

The ordering contract in docs/usage.md discusses pairs only. String-set list values are not addressed anywhere.

Existing coverage

None for ISet<string> list values.

Options

1. Document that list-value order is always caller-supplied, including for sets, and that callers wanting determinism should pass an ordered collection. Documentation only.
2. Extend canonicalization to ISet<string> so the two shapes behave alike. This is a runtime-behavior change, so a minor bump — cheap now at 0.x, more expensive after 1.0.

Worth deciding now rather than after 1.0.