Typedefs in function argument types result in wrong calling convention being used

Version and Platform (required):

• Binary Ninja Version: 4.3.7007-dev (53778246)
• OS: macOS 15.3.1
• CPU Architecture: arm64

Bug Description:
When analyzing calls to CoreFoundation functions that take typedefs such as CFAbsoluteTime or CFTimeInterval the analysis appears to treat these differently than if they the underlying double type, resulting in incorrect HLIL.

Steps To Reproduce:

1. Open a shared cache from macOS 15.3
2. Load HIToolbox, wait for analysis to complete, then navigate to __ZL38PullEventsFromWindowServerOnConnectionjhP17__CFMachPortBoost in HLIL.
3. Look at the calls to j__CFRunLoopTimerCreateWithHandler and j__CFRunLoopTimerSetNextFireDate towards the end of the function. Note the incorrect computation of the fire date.

4. Load CoreFoundation in hopes it sorts out the types.
5. Look at the same calls to j__CFRunLoopTimerCreateWithHandler and j__CFRunLoopTimerSetNextFireDate. Now the fire date for CFRunLoopTimerCreateWithHandler is also incorrectly computed.

6. Use Override Call Type on both calls to change arguments of type CFTimeInterval and CFAbsoluteTime to double. The computations are now correct!

Here are the definitions of CFTimeInterval and CFAbsoluteTime from the CoreFoundation type library:

typedef double CFTimeInterval;
typedef CFTimeInterval CFAbsoluteTime;

They should be transparent from the point of view of the calling convention and treated identically to double, but are not.

One further point of confusion is that the type for CFRunLoopTimerCreateWithHandler is absent from the CoreFoundation type library. Loading CoreFoundation in step 4 causes Binary Ninja to infer the type signature for it, but it gets it wrong. It goes with:

CFRunLoopTimerRef CFRunLoopTimerCreateWithHandler(CFAllocatorRef, CFAbsoluteTime, CFTimeInterval)

when it should be:

CFRunLoopTimerRef CFRunLoopTimerCreateWithHandler(CFAllocatorRef, CFAbsoluteTime, CFTimeInterval, CFOptionFlags, CFIndex, void (^)(CFRunLoopTimerRef))

If I explicitly set the type of CFRunLoopTimerCreateWithHandler and j__CFRunLoopTimerCreateWithHandler to the correct signature, the problem still occurs. Replacing CFAbsoluteTime and CFTimeInterval with double again fixes the problem.