Fix nRF52 remote CLI stack overflows

[mikecarper]

This is the follow-up I mentioned in PR #2824.

That PR moved nRF52 crypto onto the CC310 and recovered useful headroom in the 4 KiB Arduino loop stack. A large remote CLI command could still overflow it, though, because the command ran underneath the full packet receive/decrypt call chain. I was able to reproduce that while setting up a large region map with the additional cli options I've added.

This change copies an authenticated remote CLI command into a one-entry mailbox and processes it after Mesh::loop() returns. Advertisement signing is deferred to the following stack boundary as well, so it does not sit on top of either the receive path or the CLI handler. If another command arrives before the pending one is drained, it gets a clear busy response.

As a second layer of protection, nRF52 builds now give only the Arduino loop task an 8 KiB stack instead of the framework's 4 KiB default. Other FreeRTOS tasks keep their requested stack sizes. Serial and Ethernet CLI handling also live in a non-inlined helper so their reply buffers are gone before the mesh loop runs. We can skip this if we want to keep it at 4kb.

I added unit coverage for copying, clearing, rejecting concurrent commands, and rejecting oversized commands.

Tested with:

• pio test -e native -f test_deferred_cli_command
• pio run -e RAK_4631_repeater -e Xiao_nrf52_repeater -e heltec_v4_repeater

The RAK4631 and XIAO ELF files also contain the xTaskCreate wrapper used to resize the nRF52 loop task.