Clone dark-period violation has no debounce: one computed snapshot with the SF1000 on and the 2×4 window binary missing records a violation, a grow-log line and

Found on the dev bed: a 05:51 ‘Clone dark-period violation — SF1000 on outside the 2×4 window’ notable appeared although the 2×4 runs Independent 05:00–23:00, i.e. the lamp was inside its window. Cause on the bed was a start-up gap (lamp state arrived a few seconds before the window binaries; fixed in the simulator). The underlying weakness is real: _dark_period_violation treats a missing binary_sensor.dsc_hub_2x4_window_open as ‘window closed’ and has no hold, and the rising edge immediately writes a grow-log line, a photoperiod-conflict record and a facility notable. The live ESPHome ingest already documents that hub template binaries can be absent from a poll (it waits an extra 3 s for them), so one incomplete poll while the SF1000 is lit records a false dark-period violation — the alert that matters most for a flowering or clone schedule, now training the operator to distrust it. Fix: treat an unknown/missing window binary as unknown (no verdict), and require the condition to hold for 2+ consecutive polls or ~60 s (_held_flag, like the other held conditions) before recording.