docs: added documentation about opting-out of timeouts for graph agents

Graph-Agents.md

@@ -160,12 +160,12 @@ nodes:
   `timeout`s on `llm` nodes (which *do* route via `fallback`) as the
   operative bound, and treat the graph-level `timeout` as a generous
   backstop. `0` disables the bound entirely (equivalent to unset;
-  `--validate` flags the explicit `0` as an intentional choice) — for graphs
+  `--validate` flags the explicit `0` as an intentional choice). For graphs
   that must run until they complete, e.g. an end-to-end implementation run;
   pair it with a sane `max_loop_iterations`. **Bounds compose outward-in:**
   if this graph is run by another graph's `agent` node, that node's
   `timeout` (default 300) still applies and will drop this graph regardless
-  of its own settings — set `timeout: 0` there too. Conversely a parent's
+  of its own settings; set `timeout: 0` there too. Conversely a parent's
   `timeout: 0` does not lift a child's non-zero `settings.timeout`; the
   child's own executor enforces it. A root graph run directly is bounded
   only by its own `settings.timeout`. An unbounded run ends only on
@@ -173,7 +173,7 @@ nodes:
   super-steps, and an in-flight agent step only stops when its own loop
   observes the interrupt (a script step is killed only when its future is
   dropped). The 300s agent default was a de-facto safety net for a wedged
-  child — `timeout: 0` is the explicit opt-out of that net.
+  child; `timeout: 0` is the explicit opt-out of that net.
 - **`initial_state`:** A JSON-compatible object. Values are seeded into
   state before any node runs and are referenced from any node via `{{key}}`
   templates.