I assume the partition table and boot partition can be recreated easily, so I will focus on the ext4 partition.
The layout of the filesystem is somewhat dependent on the options used when creating it. I'll describe the common case. You can see if this matches yours by running dumpe2fs on the device (which will hopefully find all of the top-level metadata in cache rather than reading from disk).
The normal block size for ext4 filesystems is 4096 bytes, so you have lost 1024 blocks.
The first thing overwritten was block 0, the primary superblock. This is not a problem by itself, because there are backup superblocks. After that is the group descriptor table, which also has backups within the filesystem.
Then there are block bitmaps and inode bitmaps. This is where the news starts to get slightly worse. If any of these are below block 1024, which they probably are, you've lost information about which inodes and blocks are in use. This information is redundant, and will be reconstructed by fsck based on what it finds traversing all the directories and inodes, if those are intact.
But the next thing is the inode table, and here you've probably lost a lot of inodes, including the root directory, journal, and other special inodes. It will be nice to have those back. Obviously the root directory at least is still functional, or just about all commands you try to run would be failing already.
If you run a dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024 now, you'll get a backup copy of whatever is in your cache currently, mixed with the bad data for the blocks that aren't cached. Then after booting a rescue disk you can do the same dd in reverse, to put that partially-good data back on the disk, overwriting the all-bad stuff that's there now.
After this you might find automated recovery tools (fsck, testdisk) work well enough. If not, you have a map you can use to help with manual recovery. Using the "free block" lists from dumpe2fs, you know which blocks to ignore.
Most of what you lost is probably inodes. It's actually fairly likely that you had no file contents in the first 4MB of disk. (I ran mkfs.ext4 with no options on a 1TB image file, and the first non-metdata block turned out to be block 9249)
Every inode you manage to recover will identify the data blocks of a whole file. And those data blocks might be located all over the disk, not necessarily nearby.
Day 2
The dump posted on pastebin reveals great news:
Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
Primary superblock at 0, Group descriptors at 1-117
Reserved GDT blocks at 118-1141
Block bitmap at 1142 (+1142)
Inode bitmap at 1158 (+1158)
Inode table at 1174-1685 (+1174)
21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
Free blocks: 11419-32767
Free inodes: 16-8192
Since we think only 4MB at the start of the filesystem have been overwritten, we only need to worry about blocks 0-1023. And the reserved GDT blocks go all the way out to block 1141! This is the kind of damage that should be repaired by a simple e2fsck -b $backup_superblock_number (after a reboot). You could at least try that with -n to see what it thinks.
Best Answer
Try using tail to copy the file continually:
Of course, you will have to stop the tail process by hand (or some other external means) when the download has finished.