melcloud: Don't optimistically update local state

[ccrisan]

Summary

• set_device_property called the MELCloud cloud API and then immediately cached the requested value into _properties_cache, which is exactly what get_device_property() (used by every port's read_value()) returns. No confirmation that the physical device actually applied the change.
• MELCloud is a cloud-mediated device with known propagation lag/eventual consistency, making this the riskiest instance of the pattern among the addons — a rejected or delayed command would be reported as already applied.
• Same category of bug as qtoggle/qtoggleserver-zigbee2mqtt#1bc98a9.
• Fix: drop the optimistic cache write and set POLL_AFTER_WRITE = True on MELCloud, so a real device refresh (_update_devices()) runs immediately after every write instead of relying on an assumed value. DEFAULT_POLL_INTERVAL is otherwise inherited as 1800s, so without this the port could show a false "applied" value for up to 30 minutes.

Test plan

• ruff check / ruff format --check pass (verified locally)
• Manually verify against a real MELCloud account: write a property, confirm the port reflects the cloud-confirmed value (which may lag behind the requested one) rather than assuming success