Randomly modifying a filesystem image and then fixing up the checksums seems a little unfair. Would it not be reasonable to write code that assumes data that matches its checksum is valid? Isn't that the point of a checksum?
That would be absolutely unreasonable. Filesystems can be malicious, for example Stuxnet transmitted via USB flash drive.
For example (on a completely hypothetical filesystem/disk), lets say you want to open a file. You read the entry in the filesystem metadata that tells you on what sector that file begins and it gives you a value of 5005. Even if the checksum is correct, the filesystem code still needs to check that a) 5005 is actually within the range of valid sectors, b) that it actually makes sense as a sector value (maybe files must always start on a multiple of 4), c) that the data at that sector actually looks like a file, d) etc.
If you don't update the checksum as well when generating the test data then you limit the amount of depth in the testing since most errors would get caught immediately at the checksum validation stage.
Of course that means your mutations have to be "fair" in the sense that your new values should still be valid. Because as you stated, just stomping on blocks and fixing up their checksums seems like a silly test.
If you assume that, you don't need checksums in the first place.
Other than duplicating the pages (which is certainly a valid approach) how else can you recover from a data stomp?