feat: add Cosori Turbo Tower Pro (CAF-DC111S) air fryer support

[gnisch]

Adds support for the Cosori Turbo Tower Pro Smart dual-chamber air fryer (CAF-DC111S-AEU). Closes #486.

This builds on #536 by @arypien. Their four commits are included unchanged, and the last three commits here fix and extend them. If you'd rather merge #536 first, the three commits apply cleanly on top of it.

Changes on top of #536

• Tests run without pytest-asyncio. The project doesn't depend on it, so 7 of the feat: add CAF-DC111S-AEU air fryer support #536 tests failed with async def functions are not natively supported. They now use asyncio.run, like the rest of the suite.
• VeSyncAirFryerDC111 now sets self.state. Without it, to_dict(), display() and consumers that read device.state (e.g. the Home Assistant integration) raise AttributeError.
  • AirFryerDC111State.chambers holds a FryerChamberState per chamber: status, mode, recipe, set temperature, set time and remaining time, in minutes.
  • cook_status, cook_set_temp, cook_set_time and remaining_time report the active chamber, so the device exposes the same attributes as VeSyncAirFryer158. current_temp and preheat_set_time return None, as this model doesn't report them.
• Temperature unit from the device. temp_unit is normalized to celsius/fahrenheit from the status response, and startMultiCook sends that unit instead of a hardcoded 'c'.
• Input validation. Chamber, time, temperature range (from the device map) and mode are checked before any request is sent.
• Status parsing uses the shared helpers. getAirfryerMultiStatus goes through process_bypassv2_result with the AirFryerMultiStatusResult model.
• Modes. Supported modes are listed in DC111_RECIPES. Only AirFry (recipeId 14) is confirmed on a device, so it is the only entry.
• Docs. The model is added to the README, supported_devices.md and devices/kitchen.md.

Testing

• pytest: 395 passed. pylint scores 10.00/10 on the changed modules. ruff and mypy report nothing new against dev.
• Real device: a German-market unit (label CAF-DC123S-DEUR) reports itself to VeSync as CAF-DC111S-AEU / VS_WFON_CAF-DC111S-AEU_EU. It is detected, and update() fills both chambers.
• Home Assistant: running on HA 2026.9.3 with the core vesync integration pointed at this branch. The existing air fryer sensors work, provided ready is added to the HA-side cook_status options.
• Not re-tested by me: startMultiCook / endCook were validated on hardware in feat: add CAF-DC111S-AEU air fryer support #536. I only changed how their payloads are built. The physical Start button is still required.

Notes for Home Assistant

This model reports a ready status: a program is prepared and waiting for Start. HA's AIR_FRYER_MODE_MAP and the cook_status sensor options don't include it yet.

🤖 Generated with Claude Code

[arypien]

Thanks for the additional work on #552. The ready state makes sense for this device, since startMultiCook prepares the program but the physical Start button is still required.

For the user-facing status, I think ready could be presented as “Ready to operate”. This describes the state more clearly than simply “Ready”.

I think we can leave the API value as ready and only localize the displayed status in Home Assistant.