[rfsim] fix delayed sleep handling and align with radio API

[EskoDijk]

Two commits:

[rfsim] fix delayed sleep handling and align with radio API

The delayed sleep scheduled by `otPlatRadioSleep()` was not always applied.
This commit fixes that by calling `applyRadioDelayedSleep()` from more
code paths. Also, all radio platform functions are aligned to comply with
the clarified `otPlatRadio...()` API contract of OT PR #13580.

Delayed sleep related changes:

 - `platformRadioTxDone()` now applies a pending sleep once the Ack Tx is
   done.
 - the `RX_FRAME_ONGOING` timer path in `platformRadioProcess()` applies a
   pending sleep too. That path is not only a failsafe: the simulator sends
   RxDone just to the frame's addressee, so it is the normal exit for any
   frame that is overheard by a neighboring node.
 - `platformRadioRxDone()` calls `radioReceive()` now before the substate
   transitions, so that `otPlatRadioReceiveDone()` is invoked before the
   radio sleeps, as the API requires. Previously the sleep state was
   applied first, after which `radioReceive()` returned early and the
   received frame was silently dropped.

API contract related changes:

 - `otPlatRadioSleep()` returns `OT_ERROR_BUSY` while transmitting.
 - `otPlatRadioDisable()` accepts a pending transition to sleep and enacts
   it; `OT_ERROR_INVALID_STATE` now means that the radio is neither in Sleep
   state nor transitioning to Sleep state.
 - `otPlatRadioReceive()` returns `OT_ERROR_INVALID_STATE` while
   transmitting, and models the radio ramp-up time when the receive channel
   is changed. An Ack Tx that is already on air is not aborted, which is
   allowed by the API; this is done for practical reasons documented in the
   comments.
 - `otPlatRadioEnergyScan()` cancels a pending transition to sleep.

Radio state machine:

 - `setRadioState(OT_RADIO_STATE_DISABLED)` resets the substate to Ready
   instead of Startup; the startup time is applied by `otPlatRadioEnable()`.
 - the Startup -> Ready transition updates `sOngoingOperationChannel`, so
   that the simulator learns the new listening channel as soon as the
   ramp-up is done. Without this, a node stays registered on its previous
   channel until its next transmission and misses frames sent to it in
   the meantime.

[rfsim] return OT_ERROR_NONE on delayed sleep in otPlatRadioSleep

When `otPlatRadioSleep()` is called while the radio is receiving an
incoming frame, waiting in AIFS, or actively transmitting an auto-ACK,
`ot-rfsim` schedules a delayed transition to sleep (`sDelaySleep = true`)
which takes effect once the ongoing frame/ACK operation completes.

[gemini-code-assist]

Code Review

This pull request refactors the radio state machine and timing logic in ot-rfsim/src/radio.c to improve delayed sleep handling, state transitions, and channel changes. Feedback highlights a critical issue where bypassing the startup transition during an ongoing Ack transmission allows an instantaneous channel change, violating physical timing constraints. It is recommended to check for pending channel changes when exiting the IFS wait state to correctly trigger the startup ramp-up delay.

[gemini-code-assist]

When isAckOnAir is true, the transition to RFSIM_RADIO_SUBSTATE_STARTUP is bypassed to let the ongoing Ack transmission finish. However, sCurrentChannel is still immediately updated to aChannel. When the Ack transmission completes, the substate machine transitions through RX_TX_TO_RX -> IFS_WAIT -> READY and updates sOngoingOperationChannel to sCurrentChannel without ever incurring the RFSIM_RAMPUP_TIME_US ramp-up delay. This allows an instantaneous channel change, bypassing the physical timing constraints of the radio model.\n\nTo fix this, we should check if a channel change is pending when exiting RFSIM_RADIO_SUBSTATE_IFS_WAIT in platformRadioProcess(). If sCurrentChannel != sOngoingOperationChannel, we should transition to RFSIM_RADIO_SUBSTATE_STARTUP instead of RFSIM_RADIO_SUBSTATE_READY.

[EskoDijk]

The intention of the current code is that the substates RX_TX_TO_RX and IFS_WAIT together are a waiting period in which the radio transitions back to Rx; and the radio does that now on its newly scheduled/selected channel. So physically it's ok per current code: the radio takes 2*sTurnAroundTime and it could do this even faster, in 1 * sTurnAroundTime. The rampup time is equal to sTurnAroundTime.

One option is to document this intended behavior; if so I'll hear it here :)

[EskoDijk]

The failed CI test is testSimulationId; which also fails more often in other PRs and on my local machine. (Random failures) - perhaps resolve that in a separate PR.