docs: the E-1608 source kind, its probe readings and its unverified commands

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

docs/claude/architecture.md

@@ -42,6 +42,25 @@ What feeds `Acquisition` is a `DataSource`, one of the registered *kinds*.
   `[A-Za-z0-9._-]` become `_`) on port **1** (0 is rejected by the session-file parser), the kind is
   stored as `source_kind` and its settings as `source_opt_<key>`. A UDPS file keeps `<host>_<port>` and
   has neither key, so a legacy session is read as UDPS and nothing existing moves.
+- **The E-1608 kind has three layers, and only the top one knows the framework.** `e1608_link`
+  (discovery, handshake, framed TCP commands, the scan socket) and `e1608_device` (typed commands,
+  factory calibration, `decode_scans`) are plain POSIX C++ with no GTK or `DataSource` types;
+  `e1608_source` is the `DataSource`; `e1608_kind` and `e1608_panels` are the UI. A change to the wire
+  never reaches the UI files.
+- The E-1608 source runs **everything inside `poll()`** on the producer thread: posted commands, the
+  connect state machine (Down, Scanning, Halted), the scan read, the 500 ms status check, the digital
+  input/counter poll and the 20 ms waveform tick. There is no second thread. A connect attempt (discovery,
+  handshake, calibration read, scan start) can block `poll()` for as long as the command timeout allows each
+  step; that delays only the command queue. Every exception is caught inside `poll()`: an escape would end
+  the producer thread, and `drain_commands()` runs inside the same `try` for that reason.
+- Its frames are **fixed-size blocks** of about 10 ms (`round(scan_rate / 100)` scans, 1 to 4096), not
+  whatever one `recv` returned: `build_stamps` warns once when a frame's sample count differs from the
+  first one's. Digital lines and the counter are held across a block (a step trace).
+- The E-1608 panels read the board's state from `E1608Readouts`, a set of atomics the producer writes
+  and a tick callback throttled to 100 ms reads; a panel never touches the source's internals, and writes
+  only through `post()`. `Acquisition::on_event` ignores the detail string and does nothing for `Error`,
+  so the source also writes each new error to stderr as `[e1608] ...` (once per distinct message, not per
+  retry); that line is where a user sees why a connection failed.
 
 ### Data path