Byte data extraction leads to incorrect C produced

[Wall-AF]

Describe the bug
Byte extraction followed by combining the results leads to incorrect C as "byte" casting is missing (effectively ignoring the 2 MOV ?H, 0 instructions), see example:

   1018:14a1 9a 00 00     002           CALLF      KERNEL::GetVersion                               DWORD GetVersion(void)
             40 10
   1018:14a6 a3 5a 13     004           MOV        [g_nWinVer_135a],AX
   1018:14a9 c1 e8 08     004           SHR        AX,0x8
   1018:14ac b4 00        004           MOV        AH,0x0
   1018:14ae 8a 16 5a 13  004           MOV        DL,byte ptr [g_nWinVer_135a]
   1018:14b2 b6 00        004           MOV        DH,0x0
   1018:14b4 c1 e2 08     004           SHL        DX,0x8
   1018:14b7 0b c2        004           OR         AX,DX
   1018:14b9 a3 5a 13     004           MOV        [g_nWinVer_135a],AX

produces

      dwVersion = GetVersion();
      g_nWinVer_135a = (uint)dwVersion >> 8 | (uint)dwVersion << 8;

The Windows docs give the following code excerpt as their extraction mechanism:

len = sprintf(sxBuf, "Windows Version %d.%d\n", LOBYTE(LOWORD(dwVersion)), HIBYTE(LOWORD(dwVersion)));
    sprintf(szBuf + len, "Dos Version %d.%d\n", HIBYTE(HIWORD(dwVersion)), LOBYTE(HIWORD(dwVersion)));

so
g_nWinVer_135a = (uint)dwVersion >> 8 | (uint)dwVersion << 8;
should be equivalent to
g_nWinVer_135a = (HIBYTE(LOWORD(dwVersion)) >> 8) | (LOBYTE(LOWORD(dwVersion)) << 8);
but the LOBYTE(LOWORD(dwVersion)) drops the hi byte whereas (uint)dwVersion << 8 retains it.

To Reproduce
Steps to reproduce the behavior:

1. Load in the enclosed function (from the Decompile:Panels Debug Function Decompilation menu)
2. See error

Expected behavior
Correct C produced.

Screenshots
N/A

Attachments
dragmedi_isWin3.zip

Environment (please complete the following information): - OS: Windows 11

• Java Version: Temurin-21.0.3
• Ghidra Version: 11.3-DEV
• Ghidra Origin: locally built

Additional context
N/A