PDB: Fix fastcall parameter support for register parameters stored in stack slots

Version and Platform (required):

• Binary Ninja Version: 5.4.10147-dev
• Edition: Ultimate
• OS: macOS
• OS Version: 26.5
• CPU Architecture: arm64

Bug Description:
When analyzing a fastcall function that takes many arguments, the PDB parser incorrectly handles certain register-based parameters and produces an incorrect type signature.

Steps To Reproduce:
Please provide all steps required to reproduce the behavior:

1. Extract callconv.zip
2. Open callconv.dll and make sure callconv.pdb is loaded
3. Navigate to 0x10001030
4. Observe function signature looks broken

Expected Behavior:
I expected the parameters to the function to all be in their default locations and not have any cruft in the decompilation about register entry values.

Screenshots/Video Recording:

Additional Information:
Loading the binary without the pdb produces the expected HLIL:

Investigating the PDB further reveals that the PDB stores the locations of those parameters as their stack slots assigned in the function prologue, versus at call-time which is what binja expects.

Function       : static, [00001030][0001:00000030], len = 00000024, @Fastcall@24
                 Function attribute:
                 Function info: asyncheh
FuncDebugStart :   static, [0000103C][0001:0000003C]
FuncDebugEnd   :   static, [0000104E][0001:0000004E]
Data           :   VFrame Relative, [FFFFFFFC], Param, Type: int, arg1
Data           :   VFrame Relative, [FFFFFFF8], Param, Type: int, arg2
Data           :   VFrame Relative, [00000008], Param, Type: int, arg3
Data           :   VFrame Relative, [0000000C], Param, Type: int, arg4
Data           :   VFrame Relative, [00000010], Param, Type: int, arg5
Data           :   VFrame Relative, [00000014], Param, Type: int, arg6

Note FuncDebugStart being 0xC bytes into the function right after where arg1/arg2 are saved to stack slots

Reproduce the issue with callconv.dll and callconv.pdb, then inspect the PDB parser's fastcall parameter-location handling at 0x10001030. Compare the stack-slot locations recorded after FuncDebugStart with the expected call-time parameter locations; done when the analyzed signature and HLIL no longer show incorrect register-entry values.