Interop: an operator overload is chosen by the arguments in hand (backport of #3578)

[lahma]

Backport of #3578 (main squash 381dbb961), which closed #3567. Its follow-up #3585 is deliberately not included: it was ruled out for 4.x separately.

The defect, live on 4.x

JintBinaryExpression cached the selected MethodDescriptor under (operator name, left CLR type, right CLR type, ValueCoercion). Selection is InteropHelper.FindBestMatch, and several of its scoring rules read the argument value rather than its type: a number is a perfect fit for a byte parameter inside that range and no match at all outside it. Every JavaScript number reaches the key as System.Double, so 5 and 300 share one entry and whichever arrives first decides for the other.

Both halves reproduce on 4.x today, in the same process:

• m + 5 then m + 300 — System.OverflowException : Value was either too large or too small for an unsigned byte. thrown out of Engine.Evaluate (the cached operator +(RangedC, byte) is called with 300).
• m + 300 then m + 5 — no exception, the wrong answer: "object:5" where ICU-equivalent selection gives "byte:5".

Two fresh, identically configured engines disagree for the same reason, the table being process-wide.

The fix

What is cached is now the candidate set: the two-parameter operator methods the two types declare under that name, which is a reflection scan and nothing else. Selection runs per evaluation, which also retires the two embedder inputs #3424 had to key on — Options.Interop.ValueCoercion and the installed ITypeConverter are both read while scoring, so neither is in a shared table any more and Engine._engineOperatorOverloads is gone (along with Engine._valueCoercion, which existed only to be part of that key).

Three things keep the per-evaluation selection cheap:

• a pair with no operator at all leaves through the empty candidate set without allocating the argument array;
• a candidate found on both operand types (T + T, or a derived operand whose FlattenHierarchy scan reports the base's operator) is listed once instead of twice;
• FindBestMatch holds the first surviving candidate in a local and builds its list only when a second one survives, so a single-candidate resolution allocates nothing — the shape of most operator lanes and of many ordinary method calls too.

#3424's guarantee is not weakened: two engines still cannot decide for each other. It is now guaranteed by not storing a decision at all rather than by partitioning the store, so the four converter-decided and four coercion-decided tests in Jint.Tests.PublicInterface keep passing unchanged.

Divergence from the main PR

main	here	why
engine._typeConverterTargetFilter is null, ClrTypeConverter, InstallTypeConverter	engine._typeConverterIsDefault, ITypeConverter, the TypeConverter setter	4.x names; the code being deleted is the same code
docs/v5-migration.md, Jint/Runtime/Interpreter/AGENTS.md	dropped	neither exists on 4.x
—	MethodDescriptor.cs and JintUnaryExpression.cs comment updates	4.x carries two more references to the renamed table than main did. MethodDescriptor's precedent list named JintBinaryExpression._knownOperators, and JintUnaryExpression's remarks explained itself by contrast with "JintBinaryExpression's table, whose key carries the coercion setting and whose choice of table carries the converter" — true before this change, false after it. Both now name _operatorCandidates and describe what it holds. main still has the JintUnaryExpression wording, where it is equally stale — worth a follow-up there.

Everything else is byte-identical to the main patch: the Engine.cs deletion (24 lines, same as main), the InteropHelper.FindBestMatch survivor lane (applied with git apply -3, clean), and the whole of JintBinaryExpression's new GetOperatorCandidates / CollectOperatorMethods / TryOperatorOverloading.

Evidence

The five new Jint.Tests.PublicInterface cases were run against unfixed 4.x first, on both legs:

leg	before	after
net472	Failed: 3, Passed: 10, Total: 13	Failed: 0, Passed: 13
net10.0	Failed: 3, Passed: 10, Total: 13	Failed: 0, Passed: 13

The three that failed are ASmallNumberDoesNotDecideForALargeOne (the OverflowException), ALargeNumberDoesNotDecideForASmallOne (the silent wrong overload) and OneEngineSelectsPerEvaluationToo. The two single-evaluation cases passed before and after, which is what makes the other three about ordering rather than about scoring.

Jint.Tests' OperatorOverloadResolutionCacheTests is rewritten rather than added to: its three cases pinned Engine._engineOperatorOverloads, which no longer exists. The four replacing them pin the mechanism — that the set and not the selection is what is stored, that one table serves a stock engine and a converter engine alike, that a pair with no operator is remembered as having none, and that T + T is listed once. 4/4 on net472 and net10.0.

Full dotnet build -c Release: 0 errors, 0 warnings. Full dotnet test -c Release:

• Jint.Tests 7000/7000 (net10.0), 6915/6915 (net472)
• Jint.Tests.PublicInterface 1825/1825 (net10.0), 1817/1817 (net472)
• Jint.Tests.CommonScripts 28/28 both legs, Jint.Tests.SourceGenerators 52/52
• Jint.Tests.Test262 102,498 passed / 1 failed / 185 skipped of 102,684 — the one failure is intl402/supportedLocalesOf-unicode-extensions-ignored.js, the known load flake (31 s under the full run, passes in 2 s in isolation, verified). At the 4.x control of 102,499 / 0 / 185; this change cannot reach test262, which has no CLR interop.