fix(mqtt): withhold the oven setpoint when no cycle is set

[QuiteYellow]

With no cycle set the oven reports x.com.samsung.da.desired = 0, and flatten() published that straight through as target_temp_c. Home Assistant rejects it against the Number entity's declared 30-270 range on every publish:

Invalid value for number.samsung_oven_setpoint: 0 (range 30.0 - 270.0)

66,899 occurrences over three weeks on my own oven, which is how long it took me to notice.

0 is not a 0 degree target, it is the absence of a setpoint, so anything outside the settable band is now withheld. null lands as unknown on both the Number and the Setpoint sensor, the way completion_minutes already reads when the oven is idle. _setpoint applied these bounds on the write side already; only the read path was missing them.

Tests

First tests for the sample descriptors, which is why this went unnoticed for three weeks.

One of them pins a non-obvious asymmetry I got wrong on the first attempt. The write path snaps to the 5 degree step grid before bounds-checking, so 29 commits as 30 and 271 as 270, and only 0 is refused outright. Asserting that both paths reject the same inputs fails, and the code is right. The invariant that has to hold is the weaker one: every value the write path commits is one flatten() will publish back, otherwise a write appears to succeed and then reads as unknown.

Validation

• 269 tests on the branch, rebased on current main (after fix(mqtt): retire session workers on reconnect #44 and docs(protocol): clarify OwnerPSK vector scope #46)
• verified on live hardware: the oven now logs temp=0/None°C while idle instead of temp=0/0°C

Scope

mqtt_demo/ only, so nothing here ships in the smartthings-local package. No file overlap with #36, #47, #48 or #49, and all four merge clean against it.