Rename scale → scale_mode in protocol/struct layer; add control grouping future note

- `Proto_Display_Device_Info.scale` → `scale_mode`
- `Proto_Start_Display.scale` → `scale_mode`
- `PROTO_DISPLAY_CTRL_SCALE` → `PROTO_DISPLAY_CTRL_SCALE_MODE`
- `proto_write_start_display` param and all callers updated
- `on_display` callback param and all sites updated
- `Display_Slot.scale` → `scale_mode` in node
- Control name "Scale" → "Scale Mode"
- planning.md: add control grouping deferred decision

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

planning.md

@@ -136,3 +136,4 @@ These are open questions tracked in `architecture.md` that do not need to be res
 - controller_cli is a temporary dev tool; the long-term replacement is a dedicated `controller` binary outside `dev/cli/` that maintains simultaneous connections to all discovered nodes (not switching between them). Commands address a specific node by peer index. This mirrors the web UI's model of administering the whole network rather than one node at a time. The `connect` / active-connection model in the current controller_cli is an interim design choice that should not be carried forward.
 - start-ingest peer addressing: the `dest_host` + `dest_port` in START_INGEST is awkward to type manually and requires the caller to know the target's TCP port. Should accept a peer ID (index from the discovered peer table on the node) so the node can resolve the address itself. Requires the node to run discovery and expose its peer table.
 - Connection multiplexing: currently each ingest stream opens its own outbound TCP connection to the destination. Multiple streams between the same two peers should share one connection, with stream_id used to demultiplex frames. This is the priority/encapsulation scheme described in the architecture — high-priority and low-latency frames from different streams travel over the same socket rather than competing across separate sockets.
+- Control grouping: controls should be organizable into named groups for both display organisation (collapsible sections in a UI) and protocol semantics (enumerate controls within a group, set a group of related controls atomically). Relevant for display devices where scale_mode, anchor, position, and size are logically related, and for cameras where white balance, exposure, and gain belong together. The current flat list of (control_id, name, type, value) tuples does not capture this.