fix(myuplink): file the heat pump as a heat pump

[HuggeK]

myuplink declared ders: [], so the one MyUplink cloud heat-pump driver was
filed under no device type at all — absent from the Heat pump filter and
from every other one on the catalog page.
An owner searches for the device they own, and this driver could not be found
that way.

	emits via	host.emit calls	ders before	ders after
heishamon	emit_metric	0	[heatpump]	[heatpump]
nibe_local	emit_metric	0	[heatpump] (#53)	[heatpump]
myuplink	emit_metric	0	[]	[heatpump]

All three heat pumps now appear under Heat pump, and no driver in the
catalog is filed under nothing.

Important

This revisits a deliberate decision, so it deserves an explicit look rather
than a rubber stamp.

Why reversing #27's choice is the consistent move, not a new one

When #27 widened the DER vocabulary it set myuplink to none, on the reading
that ders names the emit stream a driver produces rather than the device it
covers — the driver reports through host.emit_metric and never calls
host.emit("heatpump", …).

#53 then settled the same question the other way for nibe_local, citing
heishamon as the precedent. The three drivers are the same case: all report a
pump through emit_metric only, none calls host.emit, and myuplink and
heishamon emit the same hp_* metric names. Two of the three already declared
heatpump, so myuplink was the one left behind rather than the one holding a
line.

If the opposite reading is preferred, the consistent form of it would be to
strip heatpump from heishamon and nibe_local too — which would remove the
Heat pump filter from the page entirely.

Why the version has to move — and how we know before merging

ders is copied into the signed artifact's capabilities, so this edit changes
the published bytes even though no Lua moved. That is exactly what took the
release down in #53.

This time the channel never got the chance to refuse it. The
signed channel accepts this tree check (#57) answers on the pull request, and
running it locally against the published manifest gives:

[the tree as committed: ders [heatpump], version 1.1.1]
  PASS -> {"added": [], "changed": ["myuplink"], "drivers": 80}

[the same ders change with the version put back to 1.1.0]
  REFUSED -> myuplink: changed artifact needs a higher version than 1.1.0 (published)
             -- make bump-driver ID=myuplink LEVEL=patch

A patch: no register, parameter or emitted metric changed, only the device
type the catalog files it under — the same call #53/#55 made for nibe_local.
The DRIVER table is left alone, keeping the driver byte-identical to its FTW
baseline the way #29 established.

The spec gap that allowed this

spec/manifest-v2.md documented four DER types — pv, battery, meter,
v2x_charger — where tools/validate_manifest.py accepts seven. ev,
heatpump and vehicle have been valid since #27 and are used by seven
manifests, but the field table a driver author reads never listed them. The
missing vocabulary is precisely what myuplink needed.

The table is now complete, and says what the field means for a metrics-only
driver — the ambiguity that produced three different answers for three drivers
doing the same thing. It also records that ders reaches the signed artifact,
so changing it costs a version.

Catalogs regenerated; sha256 and the Lua source are untouched.

🤖 Generated with Claude Code