Fix hyperhdrAdjust: use "brightness", not "scaleOutput"

Tested against a real HyperHDR instance rather than trusting the
schema further. scaleOutput (from the current schema-adjustment.json)
produced no visible change and no trace in serverinfo's echoed-back
adjustment state. brightness (0-100, absent from that same schema)
round-tripped correctly through serverinfo and visibly dimmed real
LEDs -- confirmed live, with piccap as the sole colour source and
only this sink's JSON-RPC calls changing anything.

A schema documents what a command accepts; it does not guarantee
what a given build actually does with each field, and this is a
mismatch between HyperHDR's current dev-branch schema and whatever
build the target instance is actually running. Switched the sink to
brightness (int 0-100) throughout: wire format, config defaults
(minBrightness/maxBrightness, 20-100), status fields, and the reset
sent on close. Renamed the frontend fields and mock to match.
Cross-compiles clean. Bumped to 1.0.4.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/configuration.md

@@ -95,18 +95,23 @@ payload so nothing fragments on a normal Ethernet MTU.
 
 ### `hyperhdrAdjust` — brightness only, via HyperHDR's JSON-RPC
 
-Sends no image at all. Instead it calls HyperHDR's `adjustment` command —
-a post-processing stage that scales output brightness regardless of which
-priority is currently active — so an existing grabber or effect keeps
-deciding colour and only overall brightness reacts to sound.
+Sends no image at all. Instead it calls HyperHDR's `adjustment` command with
+a `brightness` value (0-100) — a post-processing stage that applies
+regardless of which priority is currently active — so an existing grabber or
+capture app keeps deciding colour and only overall brightness reacts to
+sound. Confirmed against a real HyperHDR instance by watching `brightness`
+round-trip through `serverinfo` and the LEDs visibly respond; HyperHDR's own
+`schema-adjustment.json` also documents a `scaleOutput` float (0.0-2.0), but
+that field produced no effect on the same instance — what a schema declares
+and what a given build actually acts on are not always the same thing.
 
 | Key | Default | Meaning |
 | --- | --- | --- |
 | `host` | `""` | HyperHDR's address |
 | `port` | `19444` | HyperHDR's classic JSON-RPC port (not 8090, not 19400) |
 | `level` | `"rms"` | `rms` (steadier) or `peak` (punchier) |
-| `minScale` | `0.3` | brightness during silence; `1.0` is HyperHDR's normal level |
-| `maxScale` | `1.3` | brightness at full level; HyperHDR accepts up to `2.0` |
+| `minBrightness` | `20` | brightness (0-100) during silence |
+| `maxBrightness` | `100` | brightness (0-100) at full level; HyperHDR does not go above 100 |
 
 ### `udp`, `tcp`, `http`
 
@@ -193,8 +198,8 @@ broken output does not take the others down.
 Each sink adds its own fields. `packetsSent`/`bytesSent`/`sendErrors` for the
 datagram sinks, `clients`/`droppedBytes` for the stream servers,
 `connected`/`registered`/`framesSent`/`connectFailures`/`lastError` for the
-visualiser, `connected`/`updatesSent`/`minScale`/`maxScale`/`lastError` for
-the brightness sink.
+visualiser, `connected`/`updatesSent`/`minBrightness`/`maxBrightness`/`lastError`
+for the brightness sink.
 
 ### Diagnostics
 

docs/hyperhdr.md

@@ -169,15 +169,16 @@ lights go fully dark between beats, which looks dramatic and slightly broken.
 ## 4. Keep your grabber's colour, only pulse the brightness
 
 For an ambilight-style setup that already has a real colour source — a
-screen grabber, a USB capture card, an HDMI splitter — routes 1–3 all have
-the same problem: they compete for HyperHDR's priority and *replace* that
-colour with something audio-derived. This route doesn't touch colour at all.
+screen grabber, a USB capture card, a webOS capture app like piccap — routes
+1–3 all have the same problem: they compete for HyperHDR's priority and
+*replace* that colour with something audio-derived. This route doesn't touch
+colour at all.
 
-HyperHDR has a JSON-RPC `adjustment` command that scales output brightness as
-a post-processing step, applied on top of whatever priority is currently
-active. This sink sends nothing but that: no image, no priority
-registration, so the grabber keeps deciding hue and this only turns the
-result up and down with the sound.
+HyperHDR has a JSON-RPC `adjustment` command that sets output brightness
+(0-100) as a post-processing step, applied on top of whatever priority is
+currently active. This sink sends nothing but that: no image, no priority
+registration, so the grabber (or piccap, or whatever else) keeps deciding
+hue and this only turns the result up and down with the sound.
 
 ```
 TV ──RTP or local──► audiocap-service ──JSON-RPC "adjustment"──► HyperHDR
@@ -192,12 +193,21 @@ TV ──RTP or local──► audiocap-service ──JSON-RPC "adjustment"─
 | HyperHDR address | the HyperHDR machine's IP |
 | JSON-RPC port | 19444 (HyperHDR's classic control port — not 8090, the web UI; not 19400, Flatbuffers) |
 | Follows | Average level (steadier) or Peak level (punchier) |
-| Minimum brightness | `1.0` = HyperHDR's normal brightness; lower dims during quiet parts |
-| Maximum brightness | up to `2.0`; boosts past normal on loud peaks |
+| Minimum brightness | `0`-`100`; applied during quiet parts |
+| Maximum brightness | `0`-`100`; applied at full level. HyperHDR does not go above 100 |
 
 Needs a working capture source the same as every other route — see the top
-of this document for picking one. On close, the sink resets `scaleOutput` to
-`1.0` rather than leaving the LEDs stuck at whatever it last sent.
+of this document for picking one. On close, the sink resets brightness to
+`100` rather than leaving the LEDs stuck at whatever it last sent.
+
+The field is `brightness`, confirmed by watching it round-trip through
+`serverinfo` and the LEDs visibly respond on a real HyperHDR/Docker
+instance. HyperHDR's current `schema-adjustment.json` documents a
+`scaleOutput` float (0.0-2.0) instead, which looked like the obvious choice
+and is what this sink sent originally — it had no visible or server-reported
+effect on that same instance. If a future HyperHDR version drops
+`brightness`, this needs re-verifying the same way, not just re-reading the
+schema.
 
 ---