Reach a control from its chip, and write down what real use found

[Jertlok]

Two things: the quick-controls change, and a record of three bugs found in real use.

Quick controls

Tapping the ISO chip opened the whole controls sheet, then waited 250 ms for it to map and scrolled to the right row. You asked for ISO and the app gave you every setting it has, over the picture you were taking.

A chip now opens just what that chip governs, in a popover above it. The full sheet is unchanged and still a tap away on the header, for the times you do want everything.

The strip owns no state. Its sliders share the very same gtk::Adjustment as the sheet's row, so moving either moves both and the row's existing handler still fires; mode toggles and switches drive the sheet's widgets directly. There is no second copy of a value to drift, and no new wiring to keep in step — which is also why a control the camera does not have simply does not appear. A chip whose controls produce nothing compact still falls back to the sheet, so no chip becomes a dead tap.

Checks pass with 0 failures across Italian, reduced-motion, wide and landscape.

docs/known-issues.md

Three problems found using the app, each saying what was observed and what the evidence points at. The one that is not yet diagnosed says so rather than guessing.

The zoom entry is the useful one: the viewfinder, a photo and a recording each implement zoom differently. The viewfinder magnifies the already-downscaled preview (hence pixelated), a photo crops the full-resolution frame at save time (hence sharp, and framed differently from what the preview showed), and a recording ignores zoom entirely. One ScalerCrop makes all three agree and gives video zoom for free.

Also recorded: a 4K recording that saved a zero-byte file behind a spinner that never resolved, and hot pixels — measured as 5713 bright pixels at identical coordinates across two dark frames, where chance predicts 4.7.