Fix DefaultTypeConverter.Convert bypassing subclass TryConvert overrides

[lahma]

Fixes #2495

Problem

DefaultTypeConverter.Convert called the private TryConvert overload (the one with propagateException/problemMessage parameters). C# binds that overload at compile time, so subclasses overriding the public virtual TryConvert were silently bypassed on every Convert-driven interop path: DelegateWrapper, MethodDescriptor, ReflectionAccessor, ObjectWrapper.Specialized, and nested element conversions inside the converter itself. Overriding TryConvert did work for the probing callers (MethodInfoFunction, ObjectWrapper, IndexerAccessor), making the trap especially confusing — the override appeared half-working.

Fix

Convert now dispatches through the public virtual TryConvert first, so subclass overrides are honored. Only when that returns false does it fall back to the internal pipeline to produce the detailed error message ("No valid constructors found for type …", FormatException text, etc.) and to honor exception propagation semantics (Options.Interop.ExceptionHandler — raw CLR exception still propagates to the host by default, JS error with the original message under CatchClrExceptions()).

The private overload is renamed to TryConvertInternal so the silent overload binding cannot recur, and both methods now have XML docs describing the dispatch contract (override TryConvert, call base.TryConvert as fallback — never Convert, which would recurse).

No public API changes; behavior for the non-subclassed converter is unchanged on success paths, and failure paths produce identical messages/exceptions (the pipeline just runs once more to surface them).

Tests

New DefaultTypeConverterTests covering the issue repro (Action<Point> invoked with a plain JS object through an override-only converter), nested element conversions (Point[], List<Point>), direct Convert calls, detailed-error fidelity under CatchClrExceptions(), and raw exception propagation under default options.

🤖 Generated with Claude Code