feat(ui): reveal the laser's settings once a line is routed

[pskeshu]

Also fixes a regression I shipped in #162, unrelated to the disclosure — see the bottom. The device-layer Start/Stop/Log buttons have been rendering unstyled.

---

The Light panel showed everything at once, and with no device layer that meant four disabled power sliders reading an em dash — maximum clutter for zero information.

Beam and power are revealed under the Laser row when the config routes something, hidden when it doesn't.

Scope, not dependency

The nesting groups the laser's own settings. It deliberately does not imply BeamEnabled follows from the config, because it doesn't — emission is conjunctive:

emitting = armed AND routed AND power > 0

#106 is exactly what happens when someone assumes otherwise: a correctly-configured laser emitting nothing because the beam is off. So the indent carries the grouping, and the contradiction gets a line of its own rather than being softened by it. Routed lines with the beam off now reads "this configuration will not emit" and names the cause — every volume acquisition leaves BeamEnabled at No.

The mirror case matters as much: an armed beam with nothing routed is safe, surprising, and the state the rig is left in. A note on the Laser row keeps that visible. Hiding the detail must not hide the fact, or the disclosure would have made the panel less honest than the flat version.

state	revealed
config unknown	nothing — 0 sliders, was 4
ALL OFF, beam armed	nothing, plus the note
routed, beam off	detail + the contradiction stated
routed, armed, powered	detail + EMITTING

routedLines() is for display. wavelengthsOf() is unchanged and still returns every line for an unknown config — right for emitting(), because an unread config with unread power must come out unknown, not safe.

The config select now always includes what's actually set: the preset endpoint 503s with the device layer down, so the select read — while the detail below showed routed lines and live power.

The regression

The device-layer Start/Stop/Log buttons were borrowing .marking-action-btn from the old marking surface. Deleting that surface took their styling with it.

My liveness check used a regex requiring a character before "marking", so class names starting with it were never recognised as live. Second over-deletion this session with the same root cause — bulk removal on an imperfect liveness test.

Re-homed onto .devices-layer-btn, which the buttons already carried, so the name says what it styles. Test pins both.

Verified live

All four states behave as tabled above; Start is blue again with its 6px radius.