docs(sdcardio): describe the real shared-SPI CS invariant

The previous ".. important::" note said SD card init must come first on
a shared SPI bus. That rule happened to work when every co-resident CS
line had a hardware pull-up, but it is not the real invariant: what
actually matters is that every CS on the shared bus is in a known HIGH
(deselected) state before any SPI transaction. On boards where a CS
floats (e.g. the Feather RP2040 RFM, whose RFM_CS has no pull-up), it
must be driven HIGH in software; init order is secondary.

Author: mikeysklar

shared-bindings/sdcardio/SDCard.c

@@ -38,10 +38,18 @@
 //|         the microcontroller)
 //|
 //|         .. important::
-//|            If the same SPI bus is shared with other peripherals, it is important that
-//|            the SD card be initialized before accessing any other peripheral on the bus.
-//|            Failure to do so can prevent the SD card from being recognized until it is
-//|            powered off or re-inserted.
+//|            When the SPI bus is shared with other peripherals, every CS pin on
+//|            the bus must be in a known HIGH (deselected) state before any SPI
+//|            transaction occurs. This is normally guaranteed by a hardware
+//|            pull-up on each CS line, but on boards where a co-resident
+//|            peripheral's CS floats (for example the Feather RP2040 RFM, whose
+//|            ``RFM_CS`` has no pull-up), that CS must be driven HIGH in
+//|            software before the SD card is initialized. If any CS is allowed
+//|            to float low, the SPI bus can be corrupted during SD card init
+//|            and the card may not be recognized until it is powered off or
+//|            re-inserted. The order in which peripherals are constructed is
+//|            secondary; what matters is that all CS lines are deselected
+//|            before any SPI transaction.
 //|
 //|         Example usage:
 //|