I don't know if ext4 actually stores it anywhere. Other filesystems certainly don't.
ext4 avoids what it already trimmed in the current session only - while it's still mounted. Once you reboot or re-mount the filesystem, it just TRIMs empty space all over again.
So this could be an in-memory structure that isn't stored at all. I didn't dive into the very fine source code to find out.
A little test:
# truncate -s 1G /dev/shm/foobar.img
# losetup --find --show /dev/shm/foobar.img
/dev/loop9
# mkfs.ext4 /dev/loop9
# mkdir /mnt/loop
Given a 1G filesystem, let's mount and trim it:
# mount /dev/loop9 /mnt/loop/
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed
# fstrim -v /mnt/loop
/mnt/loop: 0 B (0 bytes) trimmed
So it first trims all... that alone is already suspicious, after all: mkfs already trimmed too (ouch), so it should know it's still empty and trimmed, right? Well, if it knows, it doesn't care:
# umount /mnt/loop
# mount /dev/loop9 /mnt/loop
# fstrim -v /mnt/loop
/mnt/loop: 973.4 MiB (1020678144 bytes) trimmed
So after re-mount, it just trims all free space again.
When creating and deleting files, it's not pinpoint precision either:
# dd bs=1M count=10 if=/dev/zero of=/mnt/loop/zerofile
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0124641 s, 841 MB/s
# sync
# rm /mnt/loop/zerofile
# fstrim -v /mnt/loop
/mnt/loop: 117.5 MiB (123203584 bytes) trimmed
So, writing 10M causes a re-trim of 117M. It just doesn't mean anything.
Only the SSD itself really knows what's currently trimmed and what not, and when asked to trim an already trimmed area, it should simply do nothing. So no harm done and no need to really store this information in the filesystem.