#83: Accept Node/Add/Abort during NM_WAIT_FOR_PROTOCOL

[Aydogan Ersoz (silabs-aydogane)]

Issue

• Node/Add/Abort has no effect with NM stuck in NM_WAIT_FOR_PROTOCOL #83
• JIRA: ZWAVE_SDK-2324

Closes: #83

Change

• Network management module handles abort event during NM_WAIT_FOR_PROTOCOL

Checklist

• Pull request template has been filled out correctly
• ./ci/scripts/clang-tidy.sh check has been run locally (see CONTRIBUTING.md)
• Documentation has been updated if necessary
• A Contribution License Agreement has been established between Silicon Labs (@SiliconLabs) and author's company (matching email domain)

[cursor]

PR Summary

Medium Risk
Changes inclusion abort timing and cleanup in the network management FSM, which can affect partially joined nodes and MQTT add reports.

Overview
Node add abort during protocol wait is now handled in the network management state machine when inclusion is in NM_WAIT_FOR_PROTOCOL (after a node is found but before secure bootstrapping finishes).

On NM_EV_ABORT, the stack stops the Z-Wave add with ADD_NODE_STOP_FAILED, notifies upper layers via a new notify_node_add_aborted() callback (SL_STATUS_FAIL, empty DSK, no KEX failure), then enters the existing NM_SEND_NOP / self-destruct cleanup path instead of leaving abort unhandled in that state.

The MQTT node-add report path only renames the local security_failed flag to failed; reporting logic is unchanged (non-OK status or non-none KEX still yields fail with MQTT_REASON_NODE_ADD_SECURITY_FAIL).

^{Reviewed by Cursor Bugbot for commit 8814bce. Configure here.}

[siliconlabsdevops-svc-devops]

CTT Jenkins job: $zpc_ctt_jenkins_url/job/zw-ctt-automation-multibranch/job/main/3711/