zephyr-cp: RP2040 boards are unbootable — overlays drop "ranges" from the partitions node #6

Every RP2040 overlay in ports/zephyr-cp does /delete-node/ partitions; and rebuilds the node, which silently drops the ranges; property the upstream board DTS supplies (zephyr/boards/raspberrypi/rpi_pico/rpi_pico-common.dtsi). Without it, devicetree address translation cannot walk up through flash0's ranges = <0x0 0x10000000 ...>, so the code partition resolves to an untranslated offset:

code_partition REG_IDX_0_VAL_ADDRESS = 256          /* 0x100     */
expected                             = 268435712    /* 0x10000100 */

One missing property causes two independent failures:

1. Link address. With CONFIG_FLASH_USES_MAPPED_PARTITION=y, arch/arm/cortex_m/scripts/linker.ld takes ROM_ADDR from DT_REG_ADDR(DT_CHOSEN(zephyr_code_partition)), giving FLASH (rx) : ORIGIN = 256.
2. Missing boot2. soc/raspberrypi/rpi_pico/rp2040/Kconfig gates second-stage boot on the address being exactly 0x10000100, so RP2_REQUIRES_SECOND_STAGE_BOOT goes n, and .boot2 is omitted from the ELF entirely rather than merely misplaced.

Result: zephyr.uf2 carries target addresses 0x00000100..0x00107b00 with nothing at 0x10000000, and the RP2040 falls straight back to BOOTSEL (2e8a:0003 RP2 Boot) when flashed. Confirmed on hardware.

The Pico 2 W overlay merges into the existing partitions node rather than deleting it, so it keeps ranges; and boots — that is the entire difference between the two boards.

Affected (all confirmed by regenerating artifacts, not inferred):

• raspberrypi_rpi_pico_zephyr
• raspberrypi_rpi_pico_w_zephyr
• adafruit_feather_rp2040_zephyr

So no RP2040 board in this port has ever been bootable via UF2.

Upstream Zephyr is correct here; the port was feeding it malformed devicetree.

Fixed by #13.