rp2040: add RP2350 A4 stepping support

[justinh-rahb]

Summary

Ports RP2350-related improvements from Klipper (#7141, #7146) to Katapult. The initial RP2350 scaffolding (bootrom, clocks, linker scripts, double-reset detection) was already present; this PR brings in two follow-on fixes that landed in Klipper after that initial work.

Changes

Fix RP2350 A4 stepping (from Klipper #7141)

lib/pico-sdk/pico/bootrom_constants.h: removes the runtime silicon revision check and simplifies BOOTROM_WELL_KNOWN_PTR_SIZE to the constant 2.

The original code read byte 0x13 from bootrom memory at runtime to detect whether the chip was an A2 stepping, choosing between pointer sizes of 2 and 4. All production RP2350 silicon (A4 stepping) uses size 2, making the check dead code. More critically, if it ever evaluated to 4, rom_table_lookup would be found at the wrong address, causing bootrom_reboot_usb_bootloader() and bootrom_read_unique_id() to fail silently or crash. This matches the fix in pico-sdk v2.2.0.

### RP2350b 48-GPIO support (from Klipper #7146)

The RP2350b package variant exposes 48 GPIO pins. The SIO peripheral exposes these as two banks — lo (GPIOs 0–31) and hi (GPIOs 32–47) — with each hi-bank register sitting exactly 4 bytes after its lo-bank counterpart in the struct layout.

- src/rp2040/gpio.h: adds void *sio to gpio_out and gpio_in to track which SIO bank a pin belongs to
- src/rp2040/gpio.c: adds NUM_GPIO (30 for RP2040, 48 for RP2350), updates all GPIO setup/read/write/toggle functions to store and use the sio bank pointer; for pins ≥ 32, sio = (void*)sio_hw + 4 shifts all subsequent register accesses onto the hi-bank registers without any branching in the hot path
- src/rp2040/Kconfig: expands CAN GPIO range to 0–47 for RP2350, keeps 0–29 for RP2040

Notes

• RP2040 behavior is unchanged; all RP2350-specific branches are guarded by CONFIG_MACH_RP2350 compile-time constants

[Arksine]

Thanks. It appears to me that Kevin updated the entire Pico SDK and made some changes to rp2350_bootrom.c to support the new variants. We should probably do the same to stay in sync with Klipper.

The changes to gpio.h and gpio.c look okay to me. The change to the KConfig does not appear to have been made upstream, so until Klipper supports the expanded range of GPIOs we should avoid making that change here.

[justinh-rahb]

Hello @Arksine and thanks for having a look at my PR. I will revert the changes regarding KConfig for now if everything else seems fine by you. Updating the SDK headers feels like something I could make another PR for if it's all the same with you.

[Arksine]

Thanks, I'm okay with making the SDK change in another PR. In that case it would be preferable to remove the change to the SDK header in this PR so all changes can be done once in the same place.