v2.23.3 - Signature mismatch is no longer reported as a missing entry function

A signature mismatch is no longer reported as a missing entry function

apollovm.execute returned the same diagnostic whether the entry name was absent or existed but rejected the passed arguments, so a caller that guessed the parameters was told to fix the name:

$ apollovm mcp call apollovm.execute --language dart --args '[1,2,3]' \
    --source 'int main(int a, String b){ return 1; }'
{
  "diagnostics": [
    { "severity": "error", "message": "Entry function not found: main" }
  ],
  "isError": true
}

ApolloRuntime.execute now separates the two causes. When the name exists but no overload matches, the diagnostic shows the call that was attempted — with the passed argument types — and every declared signature of that name:

No entry function matching the passed arguments: `main(int, int, int)`.
A function named `main` exists, but with a different signature:
`int main(int a, String b)`. Adjust the arguments to match a declared signature.

Several declarations are all listed, so an overload set or a name shared across classes shows the full menu:

No entry function matching the passed arguments: `run(double, double, double)`.
2 functions named `run` exist, but with different signatures:
`int A.run(int a)`, `int B.run(bool x, bool y)`.

Signatures are qualified with their class, including for a method reached through the auto-discovery order (no className given) — the case where the caller cannot otherwise tell which class answered.

An explicit className that does not exist is now reported as a missing class instead of blaming the method: Entry class not found: Bar (looking for the method `run`). A name that is genuinely absent from the source still reports Entry function not found, unchanged.

The extra lookup is read-only and runs only on the failure path, so successful execution is untouched.

Full Changelog: v2.23.2...v2.23.3