stm32/sdcard: Keep SDIO HW flow control disabled on STM32F4.

[kwagyeman]

Summary

SD card writes on STM32F4 boards can fail 100% of the time with certain cards —
every write returns a data CRC error (single block) or data timeout (multi
block) while reads work perfectly. On an OpenMV Cam M4 with a UHS-I class 64GB
SDXC card, all SD writes have been failing this way.

Root cause: hardware flow control was enabled for the SD bus in the 2021 SDIO
DMA rework
(openmv/micropython@9cd5a200a,
"Use temporary DMA buffer for SDIO transfers", to avoid FIFO under/overruns),
but the STM32F4's SDIO hardware flow control is broken silicon — per the
STM32F4 errata sheets, enabling it causes glitches on SDIOCLK that corrupt data
written to the card, and the documented workaround is "do not use HW flow
control". The failure only manifests when flow control actually engages, which
depends on the card/timing combination — which is why it has gone unnoticed
since early 2021 with many cards.

This keeps hardware flow control disabled on STM32F4 only. F7/H7/N6 keep it
enabled, where it works correctly and preserves the original under/overrun
mitigation.

Testing

• Diagnosed at register level on the failing OpenMV Cam M4 (STM32F427):
  clearing CLKCR.HWFC_EN at runtime immediately made single- and multi-block
  writes complete with read-back verification passing, on the same card that
  failed 100% before. Card checked for CSD write-protect bits (clear) to rule
  out card-side protection.
• With this change built in: file writes on the failing board/card run at
  7.9 MB/s (reads 9.7 MB/s) with content verification passing, previously 0%
  write success.
• Regression: SD read/write/CRC test runs on OpenMV Cam M7 (STM32F765) and
  OpenMV Cam H7 (STM32H743) are unaffected — those keep flow control enabled
  and their speeds are unchanged (M7: 6.2/10.3 MB/s W/R, H7: 12.2/21.7 MB/s
  W/R).

Trade-offs and Alternatives

Without hardware flow control, the F4 relies on DMA keeping the FIFO fed (which
the 2021 rework already forces) — the same configuration upstream MicroPython
has always shipped for F4, so under/overrun exposure is no worse than upstream.
The alternative of reverting flow control on all MCUs was rejected: it works on
F7/H7/N6 and serves its purpose there; only the F4 has the erratum.