Add all LoRaWAN region freq options

[srcnert]

Enables the remaining LoRaWAN regional parameter sets in the RAK4631 variant
Kconfig fragment, so a sketch can pick its region at runtime with
lorawan_set_region() instead of being limited to EU868.

• variants/rak4631_nrf52840/rak4631_nrf52840.conf: adds
  CONFIG_LORAWAN_REGION_{AS923,AU915,CN470,CN779,EU433,KR920,IN865,US915,RU864}=y
  alongside the existing EU868, in the loramac-node region order.
• sketch/lorawan/lorawan.ino: comment marking the region selection call.

Region tables are compiled into the core image, so all supported regions have to
be enabled at build time; a single core build can then serve boards deployed in
any region.

[claude]

Claude finished @srcnert's task in 2m 54s —— View job

---

Review

This enables the remaining eight LoRaWAN regional parameter sets in the RAK4631 Kconfig fragment so lorawan_set_region() can pick a region at runtime, plus a comment on the call in the sample. The variant fragment is the right place for it, the loramac region order is preserved, and nothing here touches upstream-inherited files — clean downstream-additive change.

On my earlier note about CN470/CN779/EU433: dropping CN779 was right (withdrawn in RP2, not on any RAK product). I was over-cautious on the other two — EU433 and CN470 are bands RAKwireless itself lists for the RAK4630/RAK4631 and exposes in RUI3's AT+BAND, so keeping them matches the hardware and is consistent with CONFIG_RAK_RUI_API=y. No change needed there.

Also confirmed the sample's ordering is correct: lorawan_set_region() before lorawan_start() (sketch/lorawan/lorawan.ino:166,175), which is the constraint that actually matters.

Two inline comments, both worth resolving before merge but neither a blocker on its own:

• rak4631_nrf52840.conf:56 — AS923 sub-plan (AS923-1/2/3/4) is a build-time choice in loramac, so this one symbol doesn't make the region fully runtime-selectable the way the other eight are.
• rak4631_nrf52840.conf:66 — now that a board can change region, the CONFIG_LORAWAN_NVM_SETTINGS=y restore path can silently put the MAC back on the previously-joined region; plus the NVM group grows, so existing fleets will re-join once on upgrade.

Two carry-overs from the previous round that are still open:

• Flash budget. Still unmeasured on my side — there is no Zephyr workspace in this checkout. But RAKwireless Build runs ./extra/build.sh rak4631 --mcuboot, and CONFIG_USE_DT_CODE_PARTITION=y pins the loader into the fixed 448 KB code_partition (rak4631_nrf52840_partitions.dtsi:34), so an overflow is a hard CI failure rather than something that slips through. That job was still running when I finished; if it's green the headroom question is just "how much is left", which its memory report answers.
• Sample ergonomics (non-blocking). The comment helps, but LORAWAN_REGION_EU868 is still hard-coded mid-setup(). A #define next to the other config macros at the top would make the eight new options discoverable. Fix this →

No review comments left on formatting or style — west rak-checkall (RAKwireless Checks) is green.
· branch dev/lorawan_freq