No lamp role for a plug — adopting the 4×8 light plug has nothing to bind to

The operator’s 4×8 lamp is on a smart plug not yet in DSC-HUB. The Tuya local lane is live on the Pi (tuya available/running, device_count 0) and smart_plug is can_actuate: true, so switching a plug is already possible. The blocker is the role catalogue: of 24 roles the only plug actuators are plug_pump, plug_dosing, plug_backup_dehum and plug_fan_aux. There is no lamp/light actuator role – lux_canopy is kind ‘light’ but is a sensor. So a registered plug has nothing to bind to that the photoperiod would drive. Needs: (1) a plug_light_ role, (2) something that drives it. The 4×8 photoperiod lives in hub firmware as a clock-only script, so the driver belongs in the brain – automation_rules._tick_loop now runs a real 2 s background tick (RULE_TICK_S = 2.0), so a brain-owned 4×8 light engine would have its own clock, unlike when the control-plane review was written. Minimum viable: mirror binary_sensor.dsc_hub_4x8_window_open onto the bound plug each tick, so the 4×8 runs on the hub’s clock instead of the plug vendor’s. Proper: a 4×8 light engine with the quota/debt/catch-up semantics the 2×4 already has, plus the >35C emergency-trip interlock that currently kills only the 2×4 lamp. Note a plug is on/off only – no sunrise/sunset ramp – and the vendor-app schedule must be disabled on adoption or two masters will fight over the lamp.