Clear pending Python error when a Try-style conversion fails

[jhonabreul]

What does this implement/fix?

PyObject.TryAsManagedObject (and therefore TryAs<T>/TrySafeAs<T>) converted with setError: true and returned false on failure, leaving the Python error indicator set with no one left to surface it. The stale error was then thrown by the next unrelated Python call on that thread. This was masked while the outermost Py.GIL scope deleted the thread state on dispose; since #137 pins thread states, the leaked error persists. It is the root cause of the PythonUtilTests.BothInheritedAndNonInheritedClassesWork(True) CI failure in QuantConnect/Lean#9614: an earlier test's failed TryAs<int> on a Python function left a TypeError pending that the next Python-touching test then threw.

The fix: TryAsManagedObject converts with setError: false and clears anything a conversion sub-path may have left pending before returning false. AsManagedObject keeps setError: true — fetching the error for the InvalidCastException cause consumes the indicator. Also bumps the version to 2.0.63.

Two follow-up commits close the same class of leak elsewhere:

• Converter collection/label paths: ToList handles a failed PyObject_GetIter like ToArray does (also fixing a leaked iterator reference); MakeList fails the conversion when the iterator raises mid-iteration instead of returning a silently truncated list, and clears swallowed errors when not setting errors; the type_error/overflow labels clear pending errors when not setting errors, mirroring convert_error.
• MethodBinder: overload probes convert with setError: false but can still raise (see below). When the raising candidate was probed after the candidate that matched, the pending error survived into the successful call, which then failed with SystemError: ... returned a result with an error set. Bind now clears any pending probe error once an overload has matched; the no-match path is untouched.

Why some conversion paths deliberately raise even with setError: false, and why they stay that way

The two implicit-conversion catch blocks in Converter.ToManagedValue call Exceptions.RaiseTypeError("Failed to implicitly convert {source} to {target}") unconditionally, ignoring setError. This is intentional and this PR keeps it:

• MethodBinder probes every overload with setError: false. When no overload matches, MethodBinder.Invoke checks the error indicator and, if a probe left an error, surfaces that instead of the generic "No method matches given arguments" message. A throwing implicit operator is the canonical case: without the unconditional raise, the actionable cause ("Failed to implicitly convert X to Y") would be silently discarded during probing and the user would only see the generic no-match error. This contract is covered by ImplicitConversionErrorHandling.
• Gating those raises on setError would therefore degrade diagnostics: probing always runs with setError: false, so the specific cause could never reach the user.

The consequence is that "converted with setError: false" does not guarantee "no error pending", so each API boundary that swallows a failed conversion is responsible for clearing: TryAsManagedObject clears before returning false, MakeList clears its element-conversion failures, and MethodBinder.Bind now clears once an overload has matched (keeping the error only on the no-match path, where it is the diagnostic).

Does this close any currently open issues?

Fixes the PythonUtilTests.BothInheritedAndNonInheritedClassesWork CI failure in QuantConnect/Lean#9614.

Any other comments?

Regression tests added:

• FailedTryAsDoesNotLeavePythonErrorSet — a failed TryAs<int> leaves no pending error; subsequent PyModule.FromString calls work.
• FailedAsManagedObjectRaisesWithConversionErrorAsCause — AsManagedObject still raises InvalidCastException with the Python error as its cause.
• RaisingIteratorFailsArrayConversion / OverflowConversionOnlyLeavesErrorWhenSettingErrors — these conversions fail leaving an error pending only when setError is true.
• RejectedOverloadProbeErrorDoesNotPoisonSuccessfulBind — a rejected overload's raising probe (throwing implicit operator) does not poison a successful bind of a sibling overload.

Verified end-to-end against Lean: 2.0.62 reproduces the exact CI failure when running ExtensionsTests + PythonUtilTests on a single NUnit worker; with this build all 352 tests pass. Full embedding test suite: 965 passed, 8 skipped. A full Lean test-suite sweep with a per-test PyErr-leak detector found the TryAs path to be the only leak source across 36,316 tests.

Checklist

Check all those that are applicable and complete.

• Make sure to include one or more tests for your change
• If an enhancement PR, please create docs and at best an example
• Ensure you have signed the .NET Foundation CLA
• Add yourself to AUTHORS
• Updated the CHANGELOG