After mounting, the file system is not found. The disk is visible as RAW

[Vas Das]

The computer had a veracrypt volume partition on an m.2 disk (samsung pm981a). Windows 11 system and Veracrypt v1.26.7 (updated the other day)
I bought a new disk, took out the old disk and inserted it into an m.2-nvme external box to copy data from it.
When I tried to connect the veracrypt volume, veracrypt detected corruption and suggested using the embedded header copy. But this did not find the file system, the disk was seen as RAW. I manually in the veracrypt program chose to restore the header from the embedded copy (I couldn't find an external copy, unfortunately). But nothing changed, after entering the password the disk was seen as RAW. I used R-Studio to search for file system partitions and files, but it found nothing.
I performed further actions under Linux system.
First of all, I checked the partition table - everything was fine, the Veracrypt volume partition was in its place, 4th.
Then I used dd to copy the data of this partition (dd if=/dev/sdc4 of=disk.raw ...) to keep the nvme disk in a safe state.
I have read everything I could find close to this problem
https://sourceforge.net/p/veracrypt/discussion/technical/thread/0e97094473/
https://www.wilderssecurity.com/threads/truecrypt-missing-partition-table.336671/
https://www.reddit.com/r/VeraCrypt/comments/m70wi0/sucessfully_restored_data_raw_partion_after/
https://www.reddit.com/r/VeraCrypt/comments/eiw7h6/partition_missing_after_restoration_of_volume/
However, there the problem is solved by cutting the first 512x2048 bytes before the start of the first partition, but I have the partition table intact and am working with the partition itself (sdc4) - I have no zeros, I have encrypted data from the first bytes.
Attempts to access in Linux using different header options failed too - /tmp/.veracrypt_aux_mnt1/volume has no valid data.
veracrypt -t --filesystem=none -k "" --pim=0 --protect-hidden=no disk.raw
veracrypt -t --filesystem=none -m=headerbak -k "" --pim=0 --protect-hidden=no disk.raw

However, if you enter a wrong password, veracrypt will write an error, i.e. the password is still the right one.
In this connection I have questions:
1) What happened to the Veracrypt volume and why it got corrupted
2) If the original header is corrupted, why is the embedded copy also inoperable?
3) What else can I try to salvage the data?

Anticipating questions:
1) The hardware is fully tested and functional
2) I have not done anything else except moving the disk to an external box.
3) Just in case, I checked the data before the sdc4 partition (end of sdc3) - there is no data there, just zeros

[Vas Das]

Here's what I found out.
If I connect a Veracrypt volume with the correct password, the last sectors of the volume look like this (see attachment).

However, this is the only data that can be recognized. All other data is garbage.

[Vas Das]

I found the backup header file. It's a proper backup, I'm 100% sure.
I used the command to restore the header
veracrypt -t --filesystem=none --restore-headers -k "" --protect-hidden=no disk.raw
entered a password that worked. I entered 320 random characters. Everything ended successfully. However, after trying to mount the volume, everything remained unchanged - garbage in all data (900GB+) except the end of the disk - there's an NTFS header(?) there, as in the screenshot above.
I have no idea what happened or what can be done about it. Perhaps veracrypt is not compatible with ssd in some cases?

[Vas Das]

I scanned the mounted/decrypted partition, what I get:
The size of the entire veracrypt volume partition is /tmp/.veracrypt_aux_mnt/volume
1892220416 sectors, of which there is completely random data only in 1847707648, the rest 44512768 (21735M) is zeros and NTFS headers at the end.
How could something corrupt 900GB+ of data in a few seconds (from the moment the USB nvme box is plugged in until the password is entered into veracrypt) without touching the headers (main and backup)? After all, the non-sorted data (zeros and NTFS headers) at the end of the disk indicate that decryption is working successfully.