Fix original M5Paper display refresh and SD mounting

[Decentricity]

What changed

• use the original M5Paper's canonical VSPI instance when mounting its SD card
• render original M5Paper frames directly through M5.Display, with explicit IT8951 completion waits
• leave the sprite path unchanged for every other e-paper target

Why

The first-generation M5Paper shares GPIO 12/13/14 between its IT8951 display and SD slot. Launcher previously constructed a separate SPIClass, whose ESP32 default is HSPI. SD initialization then remapped those shared pins away from M5GFX's VSPI display immediately after the initial splash. The application continued running, but the panel remained on the Launcher splash.

Changing only the SD object to another VSPI owner allowed display updates but made SD mounting unreliable. Using Arduino's canonical SPI instance coordinates both libraries on the same hardware bus. Direct IT8951 presentation also avoids stale full-screen canvas pushes on this target.

User impact

On original M5Paper hardware, Launcher now proceeds from the splash to the six-item main menu, accepts touch input, and mounts the inserted SD card instead of greying out SD.

Validation

• clean pio run -e m5stack-paper build against current main
• flashed to a first-generation M5Paper (ESP32-D0WDQ6-V3, 16 MB)
• physically confirmed main menu rendering: SD, OTA, WUI, PMan, CFG, OFF
• physically confirmed touch navigation
• serial-confirmed SDCARD mounted successfully and /config.conf load
• physically confirmed SD browsing

[bmorcelli]

Awesome!! I will test on Paper-S3 tomorrow and check if nothing broke on that side

Thank you for helping!!