Even though the Boot-Repair is booted in native UEFI style (as it could show you the efibootmgr -v output), the fix it's suggesting is related to setting up legacy-style boot on a GPT-partitioned disk. That does not seem the right fix for your situation. Be careful!
The error message about /efi/microsoft/boot/bootmgfw.efi not being found suggests that your system was originally using UEFI native boot style. With Windows, using a GPT-partitioned system disk requires UEFI boot style; you cannot mix GPT + legacy boot, like you can with Linux. Applying the suggested fix would make it impossible to select the OS to boot from GRUB; you would have to use firmware settings ("BIOS settings") to switch the boot order and/or preferred boot style to switch between the OSs.
It looks like something may have damaged the EFI System Partition (ESP). It is usually a small FAT32 partition, identified by UUID in the firmware NVRAM settings. In Debian, Ubuntu and related distributions, it is usually mounted to /boot/efi.
When using any boot repair tools, you should be careful to boot them in UEFI mode. When the system is booted in legacy mode, UEFI NVRAM boot settings will not be accessible to the repair tools. In Linux, you can use efibootmgr -v to view the boot settings if the system is in UEFI mode.
According to the efibootmgr -v output from Boot-Repair in pastebin, the partition referred as /dev/sdb2 by Boot-Repair should contain UEFI bootloaders for both OSs (Windows Boot Manager for Windows, and a Secure Boot shim + GRUB for Ubuntu). But something looks strange:
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0002,0000,0001,0004,0005
Boot0000* Windows Boot Manager HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFIUBUNTUGRUBX64.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...M................
Boot0001* Windows Boot Manager HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFIMICROSOFTBOOTBOOTMGFW.EFI)..BO
Boot0002* ubuntu HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFINEONSHIMX64.EFI)
Boot0004* UEFI OS HD(2,GPT,dc5ce41b-3e41-4a19-9f92-7883a6981bfb,0xfa000,0x31800)/File(EFIBOOTBOOTX64.EFI)..BO
Boot0005* UEFI: Imation Classic PMAP PciRoot(0x0)/Pci(0x14,0x0)/USB(3,0)..BO
The Boot0000 entry is labeled as Windows Boot Manager, but refers to \EFI\Ubuntu\grubx64.efi (I'm assuming that the lack of backslashes is an artifact of the use of Pastebin?). The Boot0001 looks basically valid for Windows (again without backslashes), but it is missing the additional BCDOBJECT data that appears in Boot0000. The primary boot entry would be Boot0002, which starts the Secure Boot shim at \EFI\Neon\shimx64.efi, which would subsequently start \EFI\Neon\grubx64.efi.
If the backslashes are actually missing in efibootmgr -v output, something may have incorrectly modified your boot NVRAM settings, or you might have a pretty severe UEFI firmware bug. See if there are firmware updates ("BIOS updates") available for your specific hardware model.
But it looks like both \EFI\Neon and \EFI\Microsoft directories may be missing fron sdb2:
/boot/efi detected in the fstab of sda3: UUID=E46B-39C6 (sdb2)
Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/bkpbootx64.efi
Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/bootx64.efi
Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/fbx64.efi
Presence of EFI/Boot file detected: /mnt/boot-sav/sdb2/EFI/Boot/grubx64.efi
Presence of bkp file detected: /mnt/boot-sav/sdb2/EFI/Boot/bkpbootx64.efi
/usr/share/boot-sav/bs-cmd_terminal.sh: line 194: warning: command substitution: ignored null byte in input
It should have detected /mnt/boot-sav/sdb2/EFI/Neon/shimx64.efi and /mnt/boot-sav/sdb2/EFI/Microsoft/Boot/bootmgfw.efi too, but didn't.
You might try booting from Windows 10 install media and using the "Repair Windows" automatic fix tool, then boot from a live Linux media, chroot into your KDE Neon installation, and then reinstall GRUB and the Secure Boot shim to the ESP (sdb2 as listed by Boot-Repair).
