You got the order backwards.
To shrink, you first shrink the filesystem (resize2fs) then second shrink the block device (mdadm). The order you did is correct for enlarging a filesystem, but backwards for shrinking one.
You've destroyed your data. To recover from this, you first confirm your backups are good. Then mkfs the array and restore from backup. If your backups aren't good, you can probably recover files that happened to be on the 1st 2TB of the filesystem. (See below)
PS: The normal way an array is managed is if a disk fails, you replace that disk with one of the same capacity or larger. mdadm --grow is not a normal part of dealing with disk failures.
Recovery
What used to be the 3rd terabyte of your filesystem has been overwritten; essentially that space is now used for the parity. (The actual sectors contain a mix of parity and data which was moved from other disks, where those sectors now contain parity.) That part of the data is gone for good; absent (possibly theoretical) high-cost approaches capable of reading the previous contents of sectors it's not recoverable.
In addition, ext4 does not keep all the metadata at the start of the filesystem; it's spread out throughout the filesystem. So you've lost a bunch of metadata as well. Importantly, if any part of the file data or metadata was in that lost third, the file will be inaccessible. Limited recovery of snippets may be possible from the 4th disk (which was probably untouched by the grow, since it was failed at the time.)
The first, and most important step, is to purchase a 4TB disk and use that to make a complete copy (image) of the filesystem. Then, set the 4 original disks aside. If there is any question of the reliability of the original disks, make a second copy and only work on one of the copies. You will also need additional disks to copy recovered files on to, including possibly multiple copies of partially damaged files.
Now you can try recovery steps on a copy. Note that most these will need to be done on a fresh copy—the steps are destructive, this is one of the many reasons to only work on a copy. Do not destroy your originals:
Let e2fsck -y /path/to/copy do it's thing. Probably it'll produce something you can mount. Go ahead and do so, copy files off.
Extend your copy back to the original size (should be OK for it to be sparse; truncate -s can do this). Then it'll likely mount (do so read-only). Copy what you can. Unmount it, and again let e2fsck -y do its thing again. Again mount and copy what you can.
Run fsck without -y and actually go through all those messages. E.g., I'd expect it actually to give you a choice of what to do when part of a file's data is in the lost area (replace with 0s, delete file). Possibly it gives choices about lost metadata too. I'd do -y first, because it will have a lot of questions for you...
If you have an old filesystem image backup, combine the 2TB you have + the missing 1TB from the backup. fsck the result, see if you can get any additional files off it. Risk that the recovered files are corrupt is quite high, though.
Use programs that scan through the filesystem image for data patterns (e.g., photorec to look for JPEGs). This is the only one that doesn't strictly need a fresh copy.
In theory, ¾ of the final ⅓ of the "failed" disk #4 contain some of your missing data. If you can figure out the sector/chunk mapping (I sure don't know it!) you could copy ~250GB from that disk back in to your image, and repeat all the above recovery steps to recover additional files.
Note that all these recovered files may have corruption in them (e.g,. blocks full of 0s instead of data). Verifying them is easy if you have checksums somewhere, but otherwise a tedious manual process.
We have a bunch of questions about recovering data from damaged filesystems; as long as you only work on copies you can experiment without putting your data at further risk.
