There are many reasons why this could happen. Probably the most likely is that writing in Linux usually happens as a writeback (where pages are buffered in the page cache, and later flushed out to disk), which can happen an indefinite amount of time after a
write(), whereas I/O counters typically measure immediate write/read throughput.
Another is that these counters really only know what Linux intends to do (and depending on the counter, that excludes even then things like writeback and I/O scheduler decisions), not your disk. Many disks independently perform operations which are not seen by the operating system. A particularly noticeable example -- not your case, but still -- are SMR disks, where even after the operating system is long done writing data, the disk will still work after the fact to move data to the shingles from faster intermediate storage.
In general, measuring I/O at the OS layer has a tendency to be inaccurate, and the counters used by
htop are not even the state of the art there. To get closer, consider using cgroup v2's
io.stat, which has more granularity and visibility of reporting.