Revert "docs(sdcardio): clarify SD-first init rule for boards with floating CS pins"

[mikeysklar]

Reverts #10947.

After further reproduction on the same hardware (Feather RP2040 RFM + Adalogger FeatherWing, CircuitPython 10.1.4 and 10.2.0-rc.0, SPI bauds 400 kHz through 8 MHz, with the RFM CS driven HIGH and floating), constructor order is not a factor in the forum-reported symptom. Both orderings succeed and both orderings fail depending on unrelated variables.

The real invariant — as @bablokb pointed out on the original PR thread — is that every CS pin on the shared SPI bus must be in a known HIGH state before any SPI transaction, whether that's guaranteed by a hardware pull-up or driven HIGH in software. The prior "SD card first" guidance only worked in practice because pull-ups on co-resident CS lines were silently doing that job. Init order is secondary.

The forum user's actual root cause turned out to be (a) a flaky/slow SD card (swapping to a SanDisk Extreme resolved the hangs) and (b) the separate macOS USB-MSC multi-sector-read stall tracked in #10766 / #10779. Neither is related to sdcardio constructor order.

Reverting so the docstring doesn't codify a non-causal rule. A follow-up PR will rewrite the .. important:: note to describe the actual invariant (all CS HIGH before any SPI transaction).

Forum thread: https://forums.adafruit.com/viewtopic.php?t=223438

[dhalbert]

If you're planning to make a new PR soon with better doc, just go ahead so we don't have two merge builds.

[mikeysklar]

Closing per @dhalbert's suggestion — folded the revert and the rewrite into #10962 so we don't run two merge builds.