perf: use hybrid sort for inline object order

[He-Pin]

Motivation:

computeSortedInlineOrder was originally optimized for evaluated inline objects with only a few fields. After strict JSON imports began constructing byte-parsed JSON objects as inline Val.Objs, kube-prometheus exposed a wider shape: imported JSON objects can have many visible fields, and the old insertion sort becomes quadratic.

Sampling a repeated kube-prometheus materialization showed Materializer.computeSortedInlineOrder as a real Scala Native hotspot. This PR keeps the small-object fast path but avoids quadratic sorting for larger inline objects.

Key Design Decision:

Use a hybrid in-place sort:

• <= 16 visible fields keep insertion sort, preserving the current small-object path.
• > 16 visible fields use in-place quicksort with insertion-sort cleanup for small partitions.
• Sorting still uses Util.compareStringsByCodepoint, so Jsonnet key ordering semantics are unchanged.
• The implementation sorts only a fresh Array[Int] index array; it does not mutate shared parsed object keys or members.

Modification:

• Refactor Materializer.computeSortedInlineOrder to delegate sorting to sortInlineOrder.
• Add insertion-sort and quicksort helpers over the index array.
• Update local performance ledgers with accepted and rejected candidates from this optimization round.

Benchmark Results:

All numbers are local, single benchmark process, no concurrent benchmark agents.

Benchmark	Baseline	Candidate	Result
Native kube forward, vs #854 binary	145.3 +/- 3.6 ms	140.0 +/- 3.2 ms	1.04x faster
Native kube reverse, vs #854 binary	151.6 +/- 10.2 ms	148.9 +/- 3.7 ms	1.02x faster
Native large_string_template guard	6.02 +/- 3.67 ms	4.52 +/- 1.27 ms	no regression observed
JVM JMH large_string_template guard	candidate 0.770 ms/op, repeat 0.723 ms/op	guard only	no relevant regression signal
jrsonnet kube reference	93.3 +/- 3.9 ms	sjsonnet candidate 146.8 +/- 12.8 ms	jrsonnet still faster

Additional profiling:

• Repeated kube materialization sample before: computeSortedInlineOrder top-stack samples 164.
• Repeated kube materialization sample after: computeSortedInlineOrder top-stack samples 63; sort-specific samples 75.

Analysis:

The change targets a structural mismatch introduced by wider inline objects from strict JSON imports. Insertion sort is optimal for 2-8 fields, but it is the wrong default for imported JSON objects with larger key sets. The hybrid threshold keeps existing small-object behavior and reduces wider-object ordering from O(n²) toward O(n log n) without boxing.

Correctness checks:

• Output equality: kube-prometheus and large_string_template outputs are byte-identical to the perf: parse strict JSON imports from bytes #854 binary.
• Focused tests: RendererTests and JsonImportFastPathTests passed.
• Formatting: ./mill --no-server --ticker false --color false -j 1 __.checkFormat passed.
• Full tests: ./mill --no-server --ticker false --color false -j 1 __.test passed (440/440).

References:

• Stacked on perf: parse strict JSON imports from bytes #854: perf: parse strict JSON imports from bytes #854
• Upstream base: cedc083
• Local commit: 90eba49e perf: use hybrid sort for inline object order

Result:

Draft stacked PR. This should be reviewed after, or together with, the strict JSON byte import PR because the main win appears on the wider inline objects enabled by that prior optimization.