docs: close last open question — graph lives in ESM web layer

Graph representation is plain ESM objects in the web interface.
No special format needed. Graph reconstruction, topology diffing,
and layout logic belong in ESM rather than C. Future TUI/CLI tools
reuse the same ESM libraries via Node.js.

No open questions remain.

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

architecture.md

@@ -807,9 +807,10 @@ These were previously open questions and are now resolved:
 - **Transport for relay edges**: TCP only for now. UDP and shared memory (for local hops) are future considerations; the transport abstraction should accommodate them without the relay needing to care which is in use.
 - **Byte budgets**: soft limits with hysteresis — two thresholds (start dropping, stop dropping) to avoid thrashing at the boundary.
 - **Relay scheduler**: strict priority first. Additional policies (round-robin, weighted round-robin, deficit round-robin, source suppression) are documented in the Relay Design section and will be added later. The scheduler interface is pluggable so policies are interchangeable without touching routing logic.
+- **Graph representation**: the graph lives in the web interface (ESM). No special format needed — plain objects, classes, and arrays. The web node queries all discovered peers for their wanted and runtime state, reconstructs the graph in-memory, and drives the UI from that. Future TUI/CLI controller tools reuse the same ESM libraries via Node.js. Complex graph logic (reconstruction, topology diffing, layout) is easier to maintain in ESM than in C and belongs there.
 
 ---
 
 ## Open Questions
 
-- What is the graph's representation format — in-memory object graph, serialized config, or both?
+None currently open.