fix: TurboBlaze fryer preheat state after set_mode and on pullOut

[ScribleSean]

Two small state fixes for VeSyncTurboBlazeFryer, against the air fryer refactor in #503. I ran into both while testing a CS358-AF for #557.

1. set_mode with preheat leaves the state as COOKING

set_mode_from_recipe always set the local status to COOKING. When the recipe has a preheat time the unit starts in the preheat phase, so until the next update() the state was wrong: is_in_preheat_mode was False and cook_from_preheat() could not see the preheat.

It now sets HEATING when the recipe has a preheat time, and COOKING otherwise.

2. A basket pulled during a cook reads as preheat

getAirfryerStatus reports preheatSetTime as 0 when the program has no preheat. get_details passed that 0 straight to set_state. FryerState.is_in_preheat_mode and is_in_cook_mode test for None, so a pullOut during a plain cook gave is_in_preheat_mode=True and is_in_cook_mode=False.

get_details now passes None for both preheat times when preheatSetTime is 0.

Tests

src/tests/test_fryer_turboblaze_state.py, using the CAF-DC601S test data:

• set_mode with a preheat time ends in HEATING and preheat mode
• set_mode without one ends in COOKING
• pullOut with preheatSetTime 0 is cook mode
• pullOut with a preheat time set is preheat mode

The first and third fail without the fix. pytest src/tests: all pass locally. ruff check and ruff format --check are clean.

Not covered

On my CS358-AF, a cook that follows a preheat still reports the original preheatSetTime while cooking, with preheatLastTime at 0. A basket pulled in that phase is still classified as preheat. Telling it apart from a pull at preheatEnd needs more than these two fields, so I left it out.

I only have a CS358-AF. The 0 for preheatSetTime matches the existing CAF-DC601S test data, but I could not check the behaviour on that model's hardware.