Camera permission and review fixes (openpanel C3, C4)

C4: a device's `viewers` (superusers by default, or members) covers the
image and video messages its ports publish. Anyone else gets none of their
values on the socket, in the catalogue or a flow's state, 403 for their
history, for the frames they hold (the last 8 included) and for TURN
credentials, no bytes when asking for them, and `bye: forbidden` for a live
view. A device credential stays bounded by its dashboards. The device page
sets it in its Camera section, and a tile the viewer may not see says
"No access to this camera" and asks the camera for nothing.

C3:
- A volatile upload is held to MAX_FRAME_BYTES (4 MiB, 413 above it, read
  without extra copies), and so is a frame on a device's socket.
- A frame the engine holds in memory is written to the ring directory
  before a local worker is handed it, so load_artifact finds it.
- A socket the bus dropped events for catches up with a snapshot, demand
  included, and a device's credential is checked again per frame, cached by
  the flow store revision and its nonce, so a lost event never keeps an
  unpaired device's frames coming.
- A report is at most 64 KB once its named config_schemas are put in place.
- A device away for 60 s has its true bool messages set to false.
- Refused frames are logged by fixed keys, a frame is named after its
  message, `fluksio serve` waits 5 s for open connections, a tile with a
  stream URL creates no demand, the 8-name cap keeps the newest names.
- Every container's log rotates (json-file, 3 x 10 MB).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0138N7k5PT4dcR1iEqXaaQ9k

docs/code/api.md

@@ -174,7 +174,10 @@ curl "$FLUKSIO/artifacts/<digest>" \
 The upload returns a reference with the content digest. Identical bytes are
 stored once. Node code uses `save_artifact` and `load_artifact` instead.
 `?volatile=true` holds the bytes in the engine's memory for a live frame, where
-newer frames push them out, instead of storing them.
+newer frames push them out, instead of storing them. Such a frame is at most
+`MAX_FRAME_BYTES` (4 MB), and a larger one is refused with 413. A camera only
+superusers may see answers 403 to anyone else for the frames its messages
+hold, the last 8 included (see [Who may watch a camera](../interface/dashboards.md#who-may-watch-a-camera)).
 
 A superuser can remove stored bytes with `DELETE /artifacts/<digest>`. While
 a run, a current message or a flow input's initial value still references the
@@ -200,8 +203,8 @@ on its own, so this is for reclaiming space sooner.
 | `GET` | `/devices/pair/{code}/device` | what is waiting on a code, before it is approved |
 | `POST` | `/devices/{id}/pair` | adopt by `{code}`, or by `{request}` from the pending list for a request from your network |
 | `POST` | `/devices/{id}/unpair` | revoke the device credential, one the portal issued included |
-| `PUT` | `/devices/{id}/report` | what the device has, from its own credential only; at most 16 KB, replaces the last report, read leniently (see [What a device reports](../interface/dashboards.md#what-a-device-reports)) |
-| `GET` | `/devices/{id}/ice` | STUN and TURN servers for a live view of the device, as `{ice_servers: [{urls, username?, credential?}], ttl}`, with TURN credentials of the caller's own; not for a device credential |
+| `PUT` | `/devices/{id}/report` | what the device has, from its own credential only; at most 16 KB, and 64 KB once its named `config_schemas` are put in place (413 above either), replaces the last report, read leniently (see [What a device reports](../interface/dashboards.md#what-a-device-reports)) |
+| `GET` | `/devices/{id}/ice` | STUN and TURN servers for a live view of the device, as `{ice_servers: [{urls, username?, credential?}], ttl}`, with TURN credentials of the caller's own; 403 for whoever may not watch its camera, and for a device credential |
 
 `/panels/pair`, `/panels/pair/{code}` and `GET /panels/{id}` answer as their
 `/devices/` counterparts, for firmware that has not updated yet.
@@ -254,7 +257,7 @@ The socket sends a snapshot followed by node, value, health, and run events.
 
 A client asks for the bytes of the media it shows with
 `{"type": "media", "names": [...]}`, which replaces what it asked for before,
-for at most 8 messages. Each frame held in memory then arrives as a binary
+for at most 8 messages, the last 8 it names when it names more. Each frame held in memory then arrives as a binary
 message before the value naming it: four bytes of header length (big endian),
 a JSON header `{"type": "media", "name", "digest", "media_type", "ts"}`, then
 the bytes. Messages are sent without per-message compression.
@@ -264,17 +267,26 @@ A device's socket is bounded to its own messages. Its snapshot carries
 `"uplink"`, `"binary"` on its own socket and `"http"` through the portal. When
 that set changes it is sent `{"type": "demand", "ports": [...]}`. A port has
 demand while a socket asks for the media of the message it is wired to, or a
-node of a running flow reads that message.
+node of a running flow reads that message. A socket that falls so far behind
+that events are dropped for it is sent a fresh snapshot, demand included, and
+is closed with 1008 if it was unpaired meanwhile.
+
+A person who may not watch a camera (see
+[Who may watch a camera](../interface/dashboards.md#who-may-watch-a-camera))
+gets none of its values in the snapshot or after it, and no frames when asking
+for them. Switching the camera's setting sends that person's open sockets a
+fresh snapshot.
 
 With a `binary` uplink the device sends a camera frame as a binary message in
 the same layout, with the header `{"type": "frame", "name": "<message>",
 "media_type": "image/jpeg", "ts": <device ms>}`. The message has to be one of
-its `in` ports wired as `image`. The frame is held in memory and published
-in one step, credited to its device node. A frame that does not qualify is
-logged and dropped and the socket stays open. With `http` it uploads with
-`PUT /artifacts?volatile=true&name=<message>` and publishes with
-`POST /messages/<message>`. A device that is unpaired or deleted while
-connected is closed with 1008.
+its `in` ports wired as `image`, and the whole message at most
+`MAX_FRAME_BYTES`. The frame is held in memory and published in one step,
+named after the message and credited to its device node. A frame that does not
+qualify is dropped, the reason logged once per socket, and the socket stays
+open. With `http` it uploads with `PUT /artifacts?volatile=true&name=<message>`
+and publishes with `POST /messages/<message>`. A device that is unpaired or
+deleted while connected is closed with 1008, at the latest with its next frame.
 
 ### Live view
 
@@ -294,10 +306,11 @@ the viewer. In order:
 | 4 | sends and hears `candidate`, the bare `candidate:...` line | hears and sends `candidate` |
 | 5 | sends `bye`, or hears `bye` or `busy` with a `reason` | hears `bye` with a `reason`, or sends `bye` or `busy` |
 
-Any signed-in person may watch any device. A device speaks only for the
-sessions it was handed on that socket. The server answers `busy` itself once a
-device has 2 sessions, and `bye` with `offline` or `unsupported` when the
-device is not connected or reports no `live` port. A session the viewer has not
+A superuser may watch any device, anyone else a device whose camera is open
+to members, and `start` is answered `bye` with `forbidden` otherwise. A device
+speaks only for the sessions it was handed on that socket. The server answers
+`busy` itself once a device has 2 sessions, and `bye` with `offline` or
+`unsupported` when the device is not connected or reports no `live` port. A session the viewer has not
 answered within 10 seconds ends with `timeout`, and either socket closing ends
 its sessions with `closed` or `offline`. A socket that falls 64 signalling
 messages behind ends the session with `overflow` instead of losing one.