feat(web): turn a driver's write path on from Settings

[HuggeK]

Every driver in the catalog reads. One of them can also write — the NIBE
S-series solar surplus feed from #537 — and turning it on meant hand-editing two
separate keys in config.yaml on the gateway: config.write.solar_pv on the
driver, and capabilities.http.allow_write on the host. Neither has a control
in Settings. An owner could install the driver from a card in the UI and then
had no way to use the one thing it was built for.

A driver now names its write paths in its own DRIVER block —
write_capabilities = { "solar_pv" } — and Settings → Devices fills a
Solar PV surplus feed panel on the drivers that declare one: a switch, and the
maximum surplus to report. A driver that declares nothing gets no panel, so
every read-only driver in the catalog is untouched.

Why a slot filled after the catalog resolves, rather than a hidden fieldset

The catalog arrives after the first render, so the tab already renders-then-
reveals for the credential fields. Reveal is the wrong shape here: a hidden
fieldset still has its inputs read by captureCurrentTab, so every HTTP driver
in the config would come back from a save carrying write: {solar_pv: false, max_w: 0} and an allow_write key — a write-block written into the config of
drivers that have no write path at all. The .drv-write-slot stays empty
markup until the driver is known to declare the path, which is also what
happens if the catalog fetch fails: nothing is rendered and nothing is
captured.

The switch keeps the properties the YAML had, where they can be seen

One switch moves both gates. Holding one without the other never wrote
anything — the host refuses http_patch without the grant, and the driver
disables the feed when host.http_patch is absent — so a half-armed config
renders as off, and saving it off changes no behaviour. Two checkboxes would
only invent a state that has to be explained.

No ceiling, no feed. The panel will not arm without a maximum above 0 W, and
clearing the maximum disarms a running feed. That ceiling is what stops a sign
error or a telemetry spike from telling a pump there are 100 kW going spare. The
driver already refuses this — in a log line, an hour later; refusing it where
the operator is looking is the same rule, findable.

The pump half is stated, not assumed — with the screens named. Installer
menu 7.5.15 set to read/write and the Solar PV input turned on cannot be
checked from FTW. Without saying so, ticking the box gets silent per-point
read only value errors. So the panel and docs/nibe-local.md name the exact
screens: menu 7.5.15, and menu 4.2.2 "solar electricity" for the enable, which
the pump titles Modbus TCP/IP Ext. (Solar PV) — register 2107, names read
live off an S735. The decommissioning note is there for the same reason: once
FTW is gone, nothing is left to clear a stale value.

Core now sends the value — the switch is end-to-end

Until this branch, arming the feed configured the gates but nothing in core
ever issued the solar_pv command; the driver's write path only ran when
something external called it. Now the control tick forwards the site's live
solar surplus to every driver whose operator armed the write gates
(allow_write + write.solar_pv + max_w > 0):

• What is sent: min(live PV generation, grid export − battery/V2X discharge), floored at 0, site-signed. Both clamps guard a real
  misattribution — a battery arbitraging into the grid must not have its watts
  advertised to the pump as free sunshine to burn.
• When: every control tick, behind the existing site-meter freshness gate.
  Repetition is deliberate — it is what feeds the driver's dead-man switch; the
  driver deadbands and rate-limits the actual device writes (validated on
  hardware in the Opt-in writable NIBE driver: feed PV production to the Solar PV registers (2107/2108/2109), later cap the electric add-heat #537 HIL run).
• When telemetry goes stale: the freshness gate already reverts every
  driver to its default mode, which clears the pump-side register — the same
  clear the dead-man enforces if commands stop arriving. No new safety
  machinery, the invariants that were already load-bearing carry this too.
• Log discipline: a refused feed can be a steady state for days (pump-side
  enable register still off), and the command repeats every few seconds, so
  refusals log on transition only — first refusal, changed refusal, recovery.

ComputeSolarFeed lives in internal/control beside ComputePVCurtail and
mirrors its shape (config-derived driver set on State, hot-reloadable, pure
function over the telemetry store). Eleven Go tests cover the surplus
arithmetic (battery/V2X exclusion, offline-driver exclusion, PV capping,
import → 0) and the config gates + log latch.

Verified against a running gateway, not only by reading

What was checked, and how

Local run at the pinned driver snapshot, GET /api/drivers/catalog:

{ "id": "nibe-local", "capabilities": ["apicreds"],
  "config_secrets": ["password"], "connection_defaults": {"port": 8443} }

— which is what makes the pump fully installable from the UI today: Host/IP,
Username, Password (from config_secrets) and the certificate fingerprint all
render, the driver defaults the port to 8443, and the backend derives
allowed_hosts from config.host. Adding write_capabilities = { "solar_pv" }
to that driver made the field appear in the same catalog response without a
restart.

A config carrying both gates round-trips POST /api/config → config.yaml →
masked GET, with the pump password preserved across a save that did not touch
it:

capabilities:
  http:
    allow_write: true
config:
  host: 192.0.2.10          # TEST-NET-1, nothing was pointed at real hardware
  write:
    max_w: 9000
    solar_pv: true

Eight tests in web/driver-write-feed.test.mjs cover the rules above, and one
Go test covers the catalog field. No write was sent to any heat pump.

Notes for review

• The bundled driver does not declare write_capabilities yet, so the panel
  does not appear until feat(nibe_local): opt-in Solar PV surplus write path (srcfl/ftw#537) device-drivers#46 lands with the declaration and
  ships through the driver channel. That is the intended order: the host offers
  a write switch only where the installed driver says it has a write path.
• feat(web): install devices by mDNS name, warn to reserve raw IPs #714 also touches web/settings/tabs/devices.js (two help-text lines); this
  branch adds a slot and a module-level function elsewhere in the file and
  rebases cleanly on it either way.
• The NIBE local-API help text told owners to enable the API in the myUplink
  app. It is generated on the pump's own screen — same correction as docs(nibe): the Local REST API is enabled on the pump, not in the app #737, which
  fixes the prose in docs/nibe-local.md; this fixes it in the UI.
• Pre-existing on this Windows box and unrelated: four internal/api tests
  (backup lifecycle, draft override, MyUplink OAuth) and web/theme-tokens.test.mjs
  fail identically on a clean master worktree; the cmd/ftw nova
  key-storage tests fail on Windows file-ownership metadata; and
  TestStaleDriverIsLeftToTheWatchdog (new in fix(control): every dispatch path reports whether the driver took the command #805) flakes on Windows'
  coarse clock — WatchdogScan(time.Nanosecond) can land on the same
  clock tick as the preceding RecordSuccess, so the driver never goes
  offline. Fails ~half of -count=20 runs here at upstream/master too;
  fine on the Linux runners.

Closes #537

🤖 Generated with Claude Code

[HuggeK]

Update: the PR body's "no write was sent to any heat pump" is now superseded
— this branch has since been run against a real S-series pump, and the write
path it exposes works end-to-end.

A dev build of this branch was deployed to a live site (host-mounted over the
stock compose install), with the srcfl/device-drivers#46 driver as a local
override. write_capabilities: ["solar_pv"] surfaced through
/api/drivers/catalog exactly as the panel expects, the armed config
round-tripped through the same masked POST /api/config path the panel
saves through (pump password preserved untouched), and a real 40 W write to
register 2109 was accepted by the pump, read back in telemetry, cleared by
the dead-man's switch, and — after a SIGKILL mid-feed — cleared again by the
startup orphan sweep.

Full findings with the log/telemetry sequence: see the HIL comment on #537.

🤖 Generated with Claude Code

[HuggeK]

The switch, rendered live. This is the panel this PR adds, captured on the real S735 validation host (dev build of this branch + device-drivers#46 driver) during the HIL run — Settings → Devices → NIBE card, with the feed armed at a 100 W ceiling:

How this was captured

Headless-browser screenshot of the running instance (no mockup): the probe confirmed panel rendered; toggle=true max_w=100 before capture, i.e. the checkbox state and ceiling shown are the values round-tripped through /api/config. The panel only exists because the local driver declares write_capabilities = { "solar_pv" } — a driver without the declaration gets an empty slot, per the PR description. The host has since been restored to the stock v1.15.0 image with write gates removed; the screenshot documents the UI, not a standing configuration.

🤖 Generated with Claude Code

[miravoss26]

Adds an opt-in write_capabilities catalog field so Settings → Devices can offer a switch for a driver's declared write path (NIBE solar-PV surplus feed) instead of requiring hand-edited YAML. A driver that declares nothing gets no panel and no capturable inputs, so read-only drivers stay untouched — verified with a dedicated Go catalog test and 8 JS tests, plus a manual round-trip against a local gateway (TEST-NET-1 address, no real hardware touched).

• The single visible toggle drives a hidden allow_write grant checkbox in sync, and the feed is blocked from (re-)arming without a ceiling > 0 on both change and initial load — matches the safety framing in the PR body.
• escHtml() is applied to the one user-influenced rendered value (max_w); no injection surface I could find.
• No secrets, no new deps, no new network destinations.

Safe to merge from my read.

[miravoss26]

Adds a Settings UI switch (and the core dispatch loop behind it) to let an operator arm the NIBE Solar PV surplus write path, instead of hand-editing config.write.solar_pv + capabilities.http.allow_write in YAML. Core now computes min(live PV, export − battery/V2X discharge) every control tick and sends it to any driver whose write gates are armed.

Correctness — read the full diff (Go + JS). The gating logic in solarFeedDriversFrom/fillWriteSlot mirrors the driver's own refusal conditions exactly (host grant + driver opt-in + ceiling > 0, one switch moves both gates together), so a UI-armed config can't diverge from what the driver would accept. solarSurplusW's clamping (cap at PV generation, subtract battery/V2X discharge, floor at 0) is covered by a solid table of unit tests including the edge cases that matter most — importing, offline PV driver, missing meter, charging vs. discharging battery. The "no ceiling → no feed" UI behavior and "clearing the ceiling disarms" are both tested in driver-write-feed.test.mjs. CI green across Go/optimizer/web.

Security screen — this is a new write path to physical hardware, so it gets the closest look: bounded by an explicit operator-set ceiling, gated behind two independent switches that both default off, degrades to 0 on stale/missing telemetry (safe direction), and reuses the existing dead-man-switch/default-mode-clear machinery rather than adding new safety plumbing. No secrets in the diff, no new network destinations (existing NIBE local API), no injection surface (payload is a JSON-encoded float). Docs (nibe-local.md) spell out the device-side menus an operator still has to set by hand, since FTW can't verify them.

One thing worth a human's eyes rather than mine: the panel doesn't render yet since the bundled driver doesn't declare write_capabilities (waiting on srcfl/device-drivers#46) — worth confirming that PR lands before this reaches users, but that's sequencing, not a defect here.

Safe to merge from my read.