If your BIOS has a boot option that says literally "Windows Boot Manager", that is a pretty strong indication that your Windows has been installed in UEFI style.The fact that the Debian installer even offers to write GRUB to the MBR indicates the Debian installer has been booted in legacy BIOS style.
A 16-bit legacy BIOS bootloader cannot chainload an UEFI bootloader (without first transitioning into either 32- or 64-bit mode and setting up an UEFI environment, which kind of defeats the purpose of being in the legacy 16-bit mode in the first place).
Usually, the boot mode (BIOS vs. UEFI) you use to boot the OS installer will automatically determine which mode the new OS to be installed will use. An OS installer running in UEFI mode could technically install a BIOS-based bootloader instead of UEFI-based one, but the opposite is generally not possible as activating the legacy BIOS compatibility requires disabling the UEFI Runtime Services interface, which is needed to write the boot settings into system NVRAM (e.g. that "Windows Boot Manager" text in the BIOS settings) - and that is a requirement to complete the installation of an UEFI bootloader.
It looks like your laptop may currently prefer booting in legacy BIOS mode over UEFI, if the boot media has both options available, and the Debian 10 installation media does indeed have both options. So it might have booted the Debian installer in BIOS mode, and thus been unable to complete the installation of an UEFI bootloader in the standard way. When in BIOS mode, the installer also won't tell you that installing an UEFI bootloader requires having an ESP (EFI System Partition) on the disk you want to install the UEFI bootloader onto. If you did not opt to create one on your HDD, there was no valid place to install the UEFI bootloader.
There is also the problem that some UEFI firmware implementations are buggy and/or Windows-centric. As the Debian Wiki says:
Many UEFI firmware implementations are unfortunately buggy, as mentioned earlier. Despite the specification for boot entries and boot order being quite clear about how things should work, there are lots of systems in the wild which get it wrong. Some systems simply ignore valid requests to add new boot entries. Others will accept those requests, but will refuse to use them unless they describe themselves as "Windows" or similar. There are lots of other similar bugs out there, suggesting that many system vendors have done very little testing beyond "does it work with Windows?"
Fortunately, the system vendors occasionally get firmware bugs fixed. So, as the first step, see if Lenovo has a an updated firmware ("a BIOS update") available for your model, and install it if there is one. That may make installing a dual-boot configuration easier.
As the second step, you probably should disable the legacy BIOS compatibility feature, if you can. If you find a "BIOS" setting that allows to force the system to UEFI only, select that setting; or there is a setting that mentions CSM ("Compatibility Support Module"), disable it. Now it should be easier to get the Debian installer to boot in UEFI mode, just like your existing Windows installation does. That will make it install the correct type of boot loader.
As the third step, be aware of the requirement to have an ESP (EFI System Partition). It is essentially a small FAT32 partition (256M is plenty for Debian 10 alone) which in Debian should be mounted to /boot/efi. If you use MBR partitioning, it should have a special partition type code 0xef; if using GPT partitioning, the partitioner option to mark a partition as "bootable" and/or "ESP" should do the right thing. Having an ESP on your HDD will allow you to move the HDD to another system and boot your existing Debian installation from it, if you want to do so later.
The alternative to creating a separate ESP on HDD for Debian is to select the Windows ESP on the SSD when setting up your partitioning, choose to not format it, but mount it with its existing filesystem as /boot/efi. The standardized directory structure on the ESP is designed to handle the bootloaders of multiple OSs on the same ESP. The UEFI bootloader of Debian 10 should fit nicely into the standard Windows 10 ESP with room to spare, if you choose this option. But you may have to go into "advanced/manual" partitioning options to do this.
If you still have problems after this, I'd recommend reading Roderick W. Smith's text on challenges with UEFI bootloaders. It's written for the rEFInd bootloader, but many things described in it are applicable to the UEFI version of GRUB also.
Once you've got both your OSs booting in UEFI style:
If your SSD is NVMe type, then it might appear in Linux as /dev/nvme0n1 (and its partitions as /dev/nvme0n1pN, N = partition number). Make sure Linux sees your SSD, then run update-grub as root.
If it doesn't say it detected Windows, run blkid as root: it should report the UUIDs of all your filesystems and partitions. Find the filesystem UUID of the Windows ESP on the SSD. If the Windows ESP uses the standard FAT32 filesystem type, it should be listed in the form UUID="xxxx-xxxx" (it's actually a FAT32 filesystem serial number).
Once you know the UUID, you can configure a custom GRUB menu entry for Windows, by adding these lines to the end of /etc/grub.d/40_custom:
menuentry 'Whatever you want the Windows 10 boot menu entry to say' {
insmod part_gpt
insmod fat
search --no-floppy --fs-uuid --set=root xxxx-xxxx
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
That should be the bare-bones UEFI chainloader entry for Windows. Just replace xxxx-xxxx with the actual Windows ESP filesystem UUID. After editing the file, run update-grub as root. Then set the default boot option to debian and you should have your boot menu.
It is possible that Lenovo has chosen to go above and beyond the UEFI specification requirements and implemented a NTFS filesystem support in their UEFI firmware, and has provided a Windows installation that uses NTFS on the ESP. In that case, replace insmod fat with insmod ntfs, and the filesystem UUID will have a different format: in blkid output will look something like UUID="A268B58668B559AD".
Note: check out the efibootmgr command. You can use it to manipulate the firmware boot settings within Linux, without entering the BIOS settings menus. In Windows, bcdedit can do the same, although its user interface is more awkward in my opinion.
