Document web node as protocol peer and future preprocessor SSoT plan

architecture.md:
- Web interface connects as a first-class binary protocol peer; no JSON
  bridge in C; DataView in JS maps directly to get_u32 etc.
- Future preprocessor section: protocol schema defined once, emits both
  C (put/get, write_*/read_*) and ESM JS (DataView encode/decode);
  same tool as planned for error location codes

planning.md:
- Add web node (entry #11) to module order
- Add Future: Protocol Preprocessor section above Deferred Decisions

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

planning.md

@@ -47,6 +47,7 @@ Modules are listed in intended build order. Each depends only on modules above i
 | 8 | `relay` | not started | Input dispatch to output queues (low-latency and completeness modes) |
 | 9 | `ingest` | not started | MJPEG frame parser (two-pass EOI state machine, opaque stream → discrete frames) |
 | 10 | `archive` | not started | Write frames to disk, control messages to binary log |
+| 11 | `web node` | not started | Node.js/Express peer — speaks binary protocol on socket side, HTTP/WebSocket to browser; `protocol.mjs` mirrors C protocol module |
 
 ---
 
@@ -62,6 +63,12 @@ Each module gets a corresponding CLI driver in `dev/cli/` that exercises its API
 
 ---
 
+## Future: Protocol Preprocessor
+
+The C `protocol` module and JavaScript `protocol.mjs` will eventually be generated from a single schema by a future preprocessor. This eliminates drift between the two implementations. The preprocessor also handles error location codes (see `common/error`). Neither the schema format nor the preprocessor tool exists yet — the hand-written implementations are the interim state.
+
+---
+
 ## Deferred Decisions
 
 These are open questions tracked in `architecture.md` that do not need to be resolved before module work begins: