interpreter: reject duplicate keys in map literals

[LeSingh1]

Fixes #1348

Problem

A map literal that contains duplicate keys was evaluated without error; the last value silently won instead of failing as the spec requires:

{1: "a", 1: "b"}         // -> {1: "b"}, no error
{"k": "x", "k": "y"}     // -> {"k": "y"}, no error
{true: 1, false: 2, true: 3}[true]   // -> 3, no error

The CEL language spec ("Aggregate Values") states: "It is an error to have duplicate keys or field names." Both cel-cpp and cel-java reject such expressions, so cel-go was inconsistent with the spec and the other implementations.

The inconsistency also exists within cel-go: the comprehension map-building path already reports the collision via mutableMap.Insert ("insert failed: key ... already exists"), but the map-literal evaluation path (evalMap.Exec) wrote into a plain Go map[ref.Val]ref.Val and never checked for duplicates.

Keys are not necessarily constant — they can be computed at runtime (e.g. {("rol" + "e"): "admin", "role": "guest"}), so the duplicate is not always visible to the type checker and must be detected during evaluation.

Fix

evalMap.Exec now rejects duplicate keys, mirroring the check already performed by mutableMap.Insert. Keys are compared using CEL equality, so equal values of different runtime types (e.g. the int 1 and the uint 1u) collide even though they are distinct Go map keys. The error is labeled with the map's AST node id, consistent with the other errors produced by evalMap.Exec.

The optional-entry path is unaffected: an entry whose optional value is absent removes the key and is not treated as a duplicate.

Verification

• Added regression tests in interpreter/interpreter_test.go covering same-type, string, heterogeneous ({0: 1, 0u: 2}), and runtime-computed duplicate keys, plus a negative case ensuring distinct heterogeneous keys still work. These run under the default, optimize (constant-folding), exhaustive, and track planner modes, and assert the error carries an AST node id.
• Confirmed the tests fail before the change (returning the last-wins value) and pass after it.
• This makes cel-go pass the previously-skipped conformance tests fields/qualified_identifier_resolution/map_value_repeat_key and map_value_repeat_key_heterogeneous, which are removed from the skip list in conformance/BUILD.bazel. Both expressions were verified to type-check (they have no disable_check) and to error at evaluation through the full cel compile+eval pipeline.
• go test ./... (excluding the bazel-only conformance package) passes with no regressions; gofmt and go vet are clean.

[TristonianJones]

/gcbrun

[TristonianJones]

I'm very happy to have this fix, though I also have a request ...

Can you introduce an option which enables or disables this feature? Previously, the last key would win, so the shift here may switch cases which would be functional into errors. This might be surprising to some users.

You might also consider adding a feature to reject map literals with repeated keys at the checker level as well since this would give a quicker rejection and reduce the number of runtime failures.

Thanks in advance!