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/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.
 
 ---