feat(thermostat): add a thermostat integration with dashboard widget

docs/specs/dashboard-flexible-layout-and-widgets.md

@@ -191,6 +191,22 @@ The signature widget: an illustration (typically the user's house) with live dev
   - Assets are deleted with their dashboard — explicitly by `dashboard.destroy` (production never sets `PRAGMA foreign_keys`, so the declared FK cascade alone would not fire on SQLite). An asset orphaned by replacing a box image lives until then; a cleanup pass can come later if it ever matters.
 - Optional **night variant**: a second image auto-swapped by sun state — **deferred**, one additive field when it comes, no schema impact.
 
+## E2. New box type: `thermostat`
+
+A circular-gauge widget for the thermostat integration (`docs/specs/thermostat.md`): current temperature and humidity, target setpoint, a preset bar and a drag-to-set dial.
+
+- New `DASHBOARD_BOX_TYPE.THERMOSTAT = 'thermostat'` in `server/utils/constants.js`. It is **not** a stretching box (absent from `TILE_STRETCH_BOX_TYPES` in `front/src/utils/dashboardSections.js`): unlike a value tile, the card is a stack of a dial, a preset bar and a status banner, so absorbing a column's leftover height would only pad the gauge with empty glass rather than make anything more readable.
+- Box config — deliberately **one device-referencing key and nothing else**:
+
+| Key | Meaning |
+|---|---|
+| `thermostat_feature` | selector of the `thermostat` / `target-temperature` feature to display |
+| `name` | optional card title override (shared with every other box type) |
+
+- **Why the config is this small.** Regulation settings — the sensor, the switch, the active schedule, the six preset temperatures, hysteresis, TPI cycle and band — are **device params**, never box fields. Putting them in `t_dashboard.boxes` would make a per-user dashboard document the source of truth of a control loop that turns real heaters on and off: the loop would have to read every dashboard on each tick, including the **private** dashboards of other users, and the same thermostat displayed on two dashboards with different settings would resolve non-deterministically. The widget chooses *which* thermostat to display; it never owns the regulation.
+- `thermostat_feature` is a device-referencing field: it is listed in `FEATURE_STRING_FIELDS` (`server/lib/device/device.migrate.js`) and in `docs/specs/device-migration.md` B.3, so migrating the thermostat device rewrites the widget's selector.
+- Values update live over the device websocket plus the `THERMOSTAT.*` messages (`PRESET_UPDATED`, `MANUAL_MODE_UPDATED`, `CONFIG_UPDATED`) the service broadcasts.
+
 ## F. AI illustration generation through Gladys Plus
 
 Generating the `house-view` illustration is the one step that cannot be beautiful-by-default from a form alone. Gladys Plus already proxies AI calls; illustration generation follows the exact same pattern.

docs/specs/device-migration.md

@@ -81,7 +81,7 @@ Two replacement maps are built once: `featureReplacements` (mapped source featur
 Fields rewritten — this list is **exhaustive and must stay in sync with the Joi schemas** of `server/models/scene.js` and `server/models/dashboard.js` (both reject unknown keys, so any new device-referencing field lands here in the same diff):
 - **Scene actions** (`t_scene.actions`, array of arrays, recursing into `condition.if-then-else`'s `if` / `then` / `else`): `device_feature` (feature), `device_features[]` (features), `device` (device), `devices[]` (devices), `camera` (device).
 - **Scene triggers** (`t_scene.triggers`, flat array): `device_feature` (feature), `device_features[]` (features), `device` (device — schema-declared legacy field, rewritten for safety).
-- **Dashboard boxes** (`t_dashboard.boxes`, array of *sections* `{ columns: [[box]] }` since the flexible layout — legacy arrays of arrays are still walked): `device_feature` (feature), `device_features[]` (features), `device` (device), `camera` (device); plus the nested selector holders introduced by the wall-panel widgets — `chips[].device_feature` (feature), `pins[].device_feature` (feature), `actions[].device_feature` (feature, quick-actions box), and the **values** of `scene_status_features` (scene selector → feature selector map; keys are scene selectors and are not rewritten). Values are replaced **in place**; array length and order never change, keeping `device_feature_names` / `units` / `colors` index-aligned.
+- **Dashboard boxes** (`t_dashboard.boxes`, array of *sections* `{ columns: [[box]] }` since the flexible layout — legacy arrays of arrays are still walked): `device_feature` (feature), `device_features[]` (features), `device` (device), `camera` (device); plus the nested selector holders introduced by the wall-panel widgets — `chips[].device_feature` (feature), `pins[].device_feature` (feature), `actions[].device_feature` (feature, quick-actions box), `thermostat_feature` (feature, thermostat box — the only device-referencing key that box carries, every regulation setting living on the device instead), and the **values** of `scene_status_features` (scene selector → feature selector map; keys are scene selectors and are not rewritten). Values are replaced **in place**; array length and order never change, keeping `device_feature_names` / `units` / `colors` index-aligned.
 
 Only scenes/dashboards that actually changed are saved. Rewritten scenes go through `SceneManager.addScene` so the RAM copy (`this.scenes`, the one `checkTrigger` iterates) and its scheduled triggers are replaced atomically with the DB copy — the same path as `scene.update`. Dashboards have no RAM cache. References to **unmapped** source features are intentionally left dangling (existing deletion semantics; the UI warned).