fix: separate LUH-O451S-WUS humidity range and mist modes from WUSR/601S

[proscar87]

Problem

The HumidifierMap entry for dev_types=['LUH-O451S-WUS', 'LUH-O451S-WUSR', 'LUH-O601S-WUS', 'LUH-O601S-KUS'] treats all four dev types identically: target_minmax=(30, 80) (the class default) and a HUMIDITY mist mode.

Both #295 and #296 show this is wrong for the LUH-O451S-WUS variant specifically (configModule WFON_AHM_LUH-A451S-WUS_US):

• Invalid humidity range for LUH-O451S-WUS (Oasismist) #296: setting a target humidity of 30 is rejected by the cloud API with "target humidity is out of range" — this device only accepts 40-80.
• Invalid humidity mode for LUH-O451S-WUS (Oasismist) #295: setting mist mode to humidity is rejected with "Mode value invaild!".

@webdjoe confirmed in #296 that this is specific to that configModule, and that the WUSR variant (WFON_AHM_LUH-A451S-WUSR_US) can go down to 30.

Fix

Split the single HumidifierMap entry into two:

• dev_types=['LUH-O451S-WUS']: target_minmax=(40, 80), HUMIDITY mode removed.
• dev_types=['LUH-O451S-WUSR', 'LUH-O601S-WUS', 'LUH-O601S-KUS']: unchanged (target_minmax=(30, 80), HUMIDITY mode kept) — no evidence these are affected.

target_minmax and mist_modes aren't just documentation — set_humidity()/set_humidity_mode() validate against them client-side before calling the API (vesynchumidifier.py), so this actually prevents the rejected calls rather than just describing them.

Splitting the dev_types list also means LUH-O451S-WUSR now gets its own entry in humidifier_modules, which the test suite auto-parametrizes from (HUMIDIFIERS = [m.setup_entry for m in humidifier_modules]) — added the corresponding fixtures (HUMIDIFIER_DETAILS/DETAILS_RESPONSES/METHOD_RESPONSES entries, recorded YAML) so it's exercised the same as every other device.

Testing

Added 4 regression tests in test_humidifiers.py:

• test_oasismist_450s_wus_rejects_humidity_below_40 / test_oasismist_450s_wusr_still_allows_humidity_30
• test_oasismist_450s_wus_has_no_humidity_mode / test_oasismist_450s_wusr_still_has_humidity_mode

These are guards on the device map, not reproductions of the API errors: the tests never reach the cloud API, so they don't produce the "target humidity is out of range" / "Mode value invaild!" messages from the issues. With device_map.py and call_json_humidifiers.py reverted to dev, all 4 fail: the two WUS tests on their local assertions (assert (30, 80) == (40, 80), and HUMIDITY still in mist_modes), the two WUSR tests with KeyError: 'LUH-O451S-WUSR' because the device-map entry doesn't exist yet. All 4 pass with the fix.

Full suite (pytest -v, Python 3.11, 3.12 and 3.13): 395 passed, 3 skipped; dev gives 380 passed, 3 skipped. pylint src/pyvesync: 10.00/10. flake8 src/pyvesync: clean. pre-commit run --all-files: passes. ruff check src/pyvesync (ruff 0.16.10) and mypy src/pyvesync (2 errors in vesyncthermostat.py) report exactly the same findings on dev and on this branch; none come from this change.

Base branch: this PR was first opened against master by mistake and carried 4 commits from dev. It now targets dev, rebased onto it, and contains only the one commit for this fix (same tree as before).

Not validated against real hardware (no OasisMist 450S on hand) — the fix is based directly on the live API traces both issues include and @webdjoe's own confirmation of the configModule-specific behavior, not guesswork about the device.

Fixes #295, fixes #296.