perf(kotlin): resolve operand paths lazily, and fix numeric comparison

[rapatao]

Summary

Replaces the Kotlin engine's per-evaluation input flattening with lazy path resolution, then fixes two numeric
correctness bugs the new test coverage exposed. Adds allocation and GC tracking to the benchmark harness, plus a wide
input variant that separates a cost scaling with the input from one scaling with the rule.

Lazy path resolution

KotlinEvaluator.call walked the whole input graph on every evaluate and materialised a flat map of every path, so
a rule reading one field of a wide object paid for every other field and every element of every list.

InputPath.resolve(root, path) now walks the input on demand, visiting only the nodes a path names. The path is
scanned in place, so a.b[0].c allocates one String per named segment and nothing else. memberProperties is
reflected once per class into a cache that also serves the name lookup.

The absence rules were read off the old parseKeys and reproduced exactly, because they decide what throws and
therefore what onFailure swallows:

path shape	exists when
""	the root is a value, a Collection or an Array
name under a Map	containsKey(name), or a key whose toString() matches
name under an object	javaClass.kotlin.memberProperties reports it
name under a value, a null, a Collection or an Array	never
[i]	the node is a Collection or Array and i is in range, by iteration order

KotlinPathResolutionTest covers the table.

Three differences from the flattened implementation, none covered by an existing test:

• KotlinContext's constructor takes Any instead of Map<String, Any?>. Source-compatible for callers passing a
  map, binary-incompatible.
• A Map key containing . or [ was a literal key in the flat map and is read as a path now.
• A property whose getter throws under reflection failed every evaluate of every rule, because flattening touched
  every property. It fails only when a rule names it now.

Numeric fixes

BigDecimal.valueOf(this.toLong()) truncated every BigDecimal operand to its integer part, on both sides of a
comparison, and overflowed above Long.MAX_VALUE:

price = BigDecimal("1.5")
"price" equalsTo "1.9"      -> true    (should be false)
"price" greaterThan "1.4"   -> false   (should be true)

A BigDecimal is now kept as it is and a BigInteger is converted directly. Equality compares numbers by value
rather than by representation, so 10 and 10.00 are the same number, which comparisons already did through
compareTo. Normalization also reaches into collections, guarded so a list without numbers is not rebuilt, which
makes listOf(1, 2) expContains 1 match.

The Rhino engine diverged on the same case: Contains delegated to indexOf, which on a java.util.List is Java
equality, so a JS number never matched a boxed Integer. It scans with == now, and throws for a non-container so
onFailure behaves as it does on the Kotlin engine.

NumberCases covers fractions, scale and numeric lists, and runs against all three engines through
BaseEvaluatorTest.

Benchmark harness

• alloc/op, total allocation, GC collections and time, and the standard deviation of an iteration are reported per
  run. Allocation comes from the JVM per-thread counter and reports n/a where it is unavailable.
• -PbenchWide=N runs the same rules against the same fields under a root carrying N extra scalar fields and an N
  element list. Wired into all three bench tasks, which now take the same arguments in the same order.
• BaseEvaluatorTest.assertWideInputMatchesDefaultInput asserts every case gives the same result against both inputs
  on every engine, so the variant measures the same work.

Measured

2000 iterations of the 173 expression suite, Apple M3 Pro with Amazon Corretto 21.0.11, three runs per configuration
in one session, medians:

engine	ops/s	avg per iteration	p50	p99	relative cost	alloc/eval
Kotlin	1,506,886	115us	83us	425us	1x	893 B
Rhino	288,132	600us	490us	1.41ms	~5.2x	11,741 B
GraalJS (reused ctx)	240,662	719us	580us	2.58ms	~6.3x	5,850 B
GraalJS	8,959	19.31ms	19.09ms	21.08ms	~168x	128,763 B

Against the flattening implementation on its own suite, lazy resolution measured 2.1x on the benchmark input and
23.8x on a wide one, where widening the input cost the flattened version 11.7x with the rules unchanged.

Input width, same session:

engine	ops/s default	ops/s wide(200)	wide is	alloc default	alloc wide(200)	wide allocates
Kotlin	1,506,886	1,768,634	unchanged	893 B	872 B	unchanged
Rhino	288,132	138,658	~2.1x slower	11,741 B	23,788 B	~2.0x more
GraalJS (reused ctx)	240,662	16,313	~14.8x slower	5,850 B	85,596 B	~14.6x more
GraalJS	8,959	5,875	~1.5x slower	128,763 B	208,161 B	~1.6x more

Both JS engines scale with input width: they inject every top-level entry of the input into the scope on every
evaluate, and the allocation factor tracks the throughput factor on both. Neither scales with depth. Width is the
largest per-evaluation cost left on reused-context GraalJS.

Test plan

• ./gradlew test green on all three engines, with the existing cases unmodified
• ./gradlew detekt koverVerify green
• ./gradlew :kotlin-evaluator:bench -PbenchIterations=2000 and the same with -PbenchWide=200