MLIL uses MediumLevelILVar(ecx) for arg params instead of MediumLevelILVarField(rcx.ecx)

Version and Platform (required):

• Binary Ninja Version: 4911
• OS: Windows
• OS Version: 10
• CPU Architecture: x64

Bug Description:
Defining a function with args in subregisters produces incorrect MLIL, as the caller passes MediumLevelILVar(ecx) instead of MediumLevelILVarField(rcx.ecx), the MLIL SSA generation interprets this as a distinct register and doesn't connect it to the superregister

Steps To Reproduce:
https://cloud.binary.ninja/bn/ad3637d5-3c86-4093-89de-a80c44d3703c

Sample asm:

func1:
    xor rax, rax
    add al, cl
    ret
func0:
    mov cl, 0x12
    call func1

Set the signature to int64_t func1(char arg1 @ cl) (or ecx, any subregister) and it gives this MLIL for the caller:

   5 @ 00401019  rcx.cl = 0x12
   6 @ 0040101b  rax_2 = func1(ecx)

Which produces this MLIL SSA

   5 @ 00401019  rcx#2.cl = 0x12 @ rcx#1
   6 @ 0040101b  rax_2#3, mem#2 = func1(ecx#0) @ mem#1

Which produces this HLIL

00401019      rcx.b = 0x12
00401027      char ecx
00401027      int32_t rdi_1 = func1(ecx)

Expected Behavior:
HLIL should be this

00401019      rcx.b = 0x12
00401027      int32_t rdi_1 = func1(rcx.ecx)

I believe this issue is here:

>>> current_function.mlil[6].operands[2][0]
<MediumLevelILVar: ecx>

This shouldn't use MediumLevelILVar(ecx), but should use MediumLevelILVarField(rcx.ecx)

Start with the linked Binary Ninja Cloud reproduction and inspect current_function.mlil[6].operands[2][0] for the subregister argument. Trace how the caller argument is represented during MLIL and SSA generation. Done means the argument uses the superregister field representation and the resulting HLIL matches the expected rcx.ecx call.