Since your system apparently boots in UEFI style, the answer to the titular question is:
efibootmgr -v as root, see the four-digit ID on the
BootCurrent: line (usually the first line of output), then look at the corresponding
BootNNNN line to find both the PARTUUID of the partition to boot from, and the filename containing the actual boot manager/loader used.
lsblk -o +PARTUUID to see the partition-unique UUIDs embedded in the GPT partition table. Find the UUID you saw on the
BootNNNN line of the
efibootmgr -v output, and you'll know the partition.
(On MBR-partitioned disks, there is no real partition UUID, and so a shorter combination of a disk signature number and a partition number is displayed in place of a real partition UUID.)
Disklabel type is definitely a factor here: it indicates your
sda uses classic MBR partitioning and boot sequence, while your
nvme0n1 uses GPT partitioning and UEFI-style booting.
While the GPT partition table can store a boot flag that is essentially the same as the
Boot flag field in the
fdisk -l output of a MBR-partitioned disk, booting MBR-style from a GPT-partitioned disk is expected to be a rare corner case, and so
fdisk -l will not include it. The native UEFI-style way will not use such a flag at all, since it's now the system firmware's job to know both the name of the bootloader file and the PARTUUID of the partition to load it from.
But if such a legacy flag is enabled on a GPT partition, using the
i command (= print information about a partition) of a modern Linux
fdisk will show it, by the presence of a
LegacyBIOSBootable keyword on the
Attrs: line of output.
To actually toggle such a flag, you would have to use the experts-only extra commands of a GPT-aware Linux
A to toggle the flag.
If you just want a list the partition table with the UEFI partition flags included, you can use
fdisk -x /dev/nvme0n1. Be advised that the output is quite a bit wider than the traditional
fdisk -l output.
If you are booting using the classic MBR/BIOS style, then the answer to the title question is "you don't, really." There is no ubiquitous standard way for BIOS-style firmware to tell the OS which device was actually used to boot the system. This was a long-standing problem on all OSs and OS installers on systems using legacy BIOS-style boot.
/sys/firmware/edd directory exists, it may contain information that allows the identification of the boot disk, by identifying the order in which BIOS saw the disks in. By convention, the current boot disk is moved to the first hard disk position (also known as "disk 0x80") in the BIOS disk list, and most BIOS-based bootloaders rely on this fact.
/sys/firmware/edd/int13_dev80 exists, and the bootloader has not switched the BIOS int13 IDs of the disks around (GRUB can do so, if you have a custom dual/multi-boot configuration that requires swapping disk IDs), then the information within may be useful to identify the actual boot disk used by the firmware.
Unfortunately the BIOS extension required to have this information available was not as widespread as it could have been, and not always completely and correctly implemented even when it was present. I've seen a lot of systems with no EDD info available, some systems with incomplete EDD info, and even one system in which querying the EDD info caused the boot to hang.
(Apparently the EDD info interface was designed by Dell, so if you mostly work with Dell systems, you may have better luck than me.)