docs(sdcardio): replace init-order note with the real shared-SPI CS invariant

[mikeysklar]

Supersedes #10947 and #10961. Per @dhalbert's note on #10961, folding the revert and the rewrite into one PR so we don't run two merge builds.

What this does

• First commit reverts docs(sdcardio): clarify SD-first init rule for boards with floating C… #10947 (the "SD-first with an exception for floating CS" framing).
• Second commit rewrites the existing .. important:: note on sdcardio.SDCard.__init__ to describe the actual invariant on a shared SPI bus.

Why

The previous note said the SD card must be initialized before any other peripheral on a shared SPI bus. That rule worked in practice because every co-resident CS line on the supported boards had a hardware pull-up silently keeping the bus clean at boot — not because SD card init has to come first. As @bablokb pointed out on #10947, the real invariant is that every CS pin on the shared bus must be in a known HIGH (deselected) state before any SPI transaction, whether guaranteed by a hardware pull-up or driven HIGH in software. Init order is secondary.

The Feather RP2040 RFM is the board that exposes the gap: RFM_CS has no pull-up, so it floats and corrupts the bus during SD init unless the user drives it HIGH first. #10947 tried to document this as an "exception to the SD-first rule" — but the SD-first rule itself was only ever a proxy for the real CS-state invariant, so documenting the invariant directly is the correct fix.

Context

• Forum thread that prompted the investigation: https://forums.adafruit.com/viewtopic.php?t=223438
• Prior PR being replaced: docs(sdcardio): clarify SD-first init rule for boards with floating C… #10947
• Revert-only PR now superseded: Revert "docs(sdcardio): clarify SD-first init rule for boards with floating CS pins" #10961

[dhalbert]

If this slight clarification is fine with you, you or I can just apply the suggestion, and then I'll approve and merge.

Thanks for the clarification and rewrite.

[mikeysklar]

Looks good. Thx dan.

[bablokb]

the SPI bus can be corrupted

Maybe this is nitpicking, but is this really true? I don't think the SPI bus cares about the data. I think the core problem is that a floating CS might fool a peripheral into thinking that data on the bus is for itself, thus corrupting the device state because most probably it receives wrong commands.