test(csharp): compare MAP columns order-insensitively in E2E tests

[eric-wang-1990]

Problem

ComplexTypesValueTests.TestMapData and ClientTests.VerifyTypesAndValues compare a serialized MAP column by exact JSON string, which bakes in a specific key order. But Databricks MAP key order is unspecified — the MAP type is an unordered set, and the server demonstrably returns keys in different orders on different runs.

This surfaced in #509's merge queue: on the identical commit, E2E (thrift + rest) passed at 17:39 (server returned sorted keys) and failed at ~22:00 (server returned insertion order):

Expected: {"Jack Doe":3,"Jane Doe":2,"John Doe":1}
Actual:   {"John Doe":1,"Jane Doe":2,"Jack Doe":3}

#509 removed the client-side SortedDictionary in ComplexTypeSerializingStream that used to normalize map output to sorted order (on both Thrift and SEA — both wrap with that serializer). That normalization was masking the fact that these tests asserted an order the server never guaranteed. With it gone, the tests flake on both protocols.

Why not just re-sort in the driver?

Because the driver shouldn't. JDBC — the reference contract this driver matches — does not sort map keys; it preserves the server's order via LinkedHashMap. The old SortedDictionary was an ADBC-only divergence from JDBC (and a string sort, so it mis-ordered numeric keys as 1,10,2). #509's no-sort behavior is the more JDBC-conformant, spec-faithful choice. The tests are what needed fixing.

Fix

Assert map content, not an unspecified key order:

• Add DatabricksTestEnvironment.NormalizeMapJson — sorts the top-level object's keys (Ordinal), preserving each value's raw JSON so nested STRUCT field order (which is significant) is untouched.
• TestMapData override and the VerifyTypesAndValues map sample column now compare NormalizeMapJson(expected) vs NormalizeMapJson(actual) (the latter via the existing isValid validator hook).

No driver/serializer changes; no submodule or upstream arrow-adbc changes.

Verification

• dotnet build of the test project succeeds.
• Normalization is applied to both sides identically, so the assertion is invariant to the server's key order — fixing the flake on both Thrift and SEA. (Cannot run the E2E suite locally — needs a live warehouse; relies on CI, which is where the failure reproduced.)

Unblocks #509's merge queue: order-insensitive comparison passes on both the old (sorted) and #509 (server-order) serializer output, so this can land on main independently, after which #509 rebases and passes.

This pull request and its description were written by Isaac.

[peco-review-bot]

Verdict: 1 Low

Looks good — a focused test-only fix that compares MAP columns by content rather than an unspecified server key order. NormalizeMapJson, the ColumnNetTypeArrowTypeValue(..., bool, isValid) overload it uses, and the overridden ValidateTestMapData all line up correctly; normalization is applied identically to both sides so the assertion is order-invariant. One low note about the normalization being intentionally shallow (top-level keys only).

[peco-review-bot]

✅ No issues identified by the review bot.