Fix trimmable typemap constructor UCO generation

[Copilot]

Generated trimmable typemap constructor UCO wrappers were activating peers through the (IntPtr, JniHandleOwnership) constructor even when Java invoked a managed constructor with parameters. This skipped JNI argument resolution and called the wrong constructor.

• Constructor metadata flow

  • Carry concrete managed constructor parameter types from scanner results into the typemap model.
  • Preserve the declaring type/assembly for constructor calls emitted into the typemap assembly.

• UCO IL generation

  • Emit direct calls to the matching managed constructor when available.
  • Convert JNI object parameters with JavaConvert.FromJniHandle<T>().
  • Set the peer reference before invoking the managed constructor.
  • Keep activation-only fallback behavior for inherited seed constructors with no concrete managed constructor.

• Regression coverage

  • Add generator tests that inspect emitted IL for:
    • nctor_*_uco calling the matching managed constructor.
    • JNI object handle conversion before constructor invocation.

Example generated behavior now follows the Java constructor signature:

// Java invokes: nctor_1(self, contextHandle)
// Generated UCO now resolves contextHandle and calls:
obj.SetPeerReference(new JniObjectReference(self));
obj.CustomView(JavaConvert.FromJniHandle<Context>(
    contextHandle,
    JniHandleOwnership.DoNotTransfer));