fix: sort ASCII-safe strings by runtime kind

[He-Pin]

Motivation:
Val.AsciiSafeStr is a Val.Str subclass used by renderer/string optimizations. std.sort was using exact runtime class equality to validate and dispatch sortable values, so arrays containing AsciiSafeStr could fail even though Jsonnet semantics treat those values as strings.

Key Design Decision:
Classify values by Jsonnet runtime kind rather than exact JVM/Native class. This preserves the existing specialized string/number/array sort paths while making subtype-based string optimizations semantically transparent to the standard library.

Modification:

• Add small integer sort-kind classification in SetModule.
• Replace exact getClass checks in default sorting and key-function sorting with sort-kind checks.
• Add a regression in new_test_suite/set_sort_ascii_safe_strings.jsonnet for all-AsciiSafeStr, mixed Str/AsciiSafeStr, and key-function-produced AsciiSafeStr sorting.

Benchmark Results:
This is a correctness/enabler PR, not a claimed performance win. On the Scala Native 0.5.12 stacked profiling branch, kube-prometheus output stayed byte-identical; sort-kind-only A/B was neutral: forward 194.3 ± 14.6 ms clean vs 187.9 ± 12.3 ms candidate, reversed 170.7 ± 2.7 ms clean vs 172.0 ± 1.6 ms candidate.

Analysis:
The exact-class check was brittle because optimized runtime value subclasses must remain semantically indistinguishable from their base Jsonnet type. The replacement also avoids closure-based forall(_.getClass == keyType) checks in this path, but the important result is that future AsciiSafeStr propagation can be evaluated without breaking std.sort.

References:

• Discovered while evaluating broader short-string AsciiSafeStr propagation for the Scala Native 0.5.12 performance work.

Result:

• ./mill --no-server --ticker false --color false __.reformat passed.
• ./mill --no-server --ticker false --color false -j 1 __.test passed 444/444.