sensor list <start> wraps a large start negative and prints NULL names #43

sensor list <start> in CommonCLI.cpp parses start with _atoi(), which returns a uint32_t, into an int.

What goes wrong:

• A start of 4294967295 becomes -1, and 2147483648 becomes INT_MIN. Both pass the start >= end guard, so the loop asks the sensor manager for negative indexes.
• ZephyrSensorManager::getSettingName() and getSettingValue() return NULL for those, and the NULLs go straight into "%s=%s\n". That is undefined behaviour; picolibc happens to print (null).
• 4294967296 wraps _atoi() itself to 0 and lists from the start.
• Pages are bounded by a fixed dp - reply < 134 inside a CLI_REPLY_SIZE (256) bound, not by the buffer actually passed.

Reproduced on the host with the handler lifted verbatim from dev and one setting (gps=1):

[sensor list 4294967295] -> [1 vars|(null)=(null)|gps=1]
[sensor list 2147483648] -> [1 vars|(null)=(null)| ...ten rows... |... next:-2147483638]
[sensor list 4294967296] -> [1 vars|gps=1]

It is reachable remotely: sensor list is an admin CLI command. It does not crash, since picolibc substitutes (null).

Fix direction (the same as meshcore-dev/MeshCore#3433): clamp the start index while it is parsed, end the listing on a NULL name or value, and bound pages by the real buffer, keeping room for the ... next:N marker.

Found by evaluating MeshCore's #3433 against ZephCore, under the policy of keeping the two in step.