This byte needs to be read before the card goes busy, but more importantly,
it would otherwise be read out by sd_wait_ready():
For cards where this byte is 0xff, sd_wait_ready() would think the card is
immediately ready and let the code send it the next command, while the read
actually made the card go busy.
This makes the card end up in a state the code cannot recover it from - even
if you reboot the machine so spisd.device is restarted, it still requires
the card to be power cycled by ejecting and re-inserting it.
How to reproduce for affected cards:
1. Use spisd.device v2.2
2. Mount SD0:
3. Write a file larger than 512Bytes to trigger a write multiple block
4. Write or read another file, this will trigger the next command and show
the issue as a read or write error