docs: Improved the formatting of a few of the new graph agent docs

Graph-Agents.md

@@ -322,8 +322,8 @@ resolved strictly (a missing key fails the node before the child starts, with
 **Two things are rejected**, both at load time by the validator and again at
 runtime for graphs running with `validate_before_run: false`. The validator
 messages below name the node; the runtime guards name the agent instead
-(`agent '<name>' has no graph.yaml; …` / `agent '<name>': `inputs.initial_prompt`
-is reserved …`) and arrive wrapped in the usual `at node '<id>': Agent '<name>'
+(`agent '<name>' has no graph.yaml; ...` / `agent '<name>': `inputs.initial_prompt`
+is reserved ...`) and arrive wrapped in the usual `at node '<id>': Agent '<name>'
 failed:` context, so the node is still recoverable from the error chain.
 
 - `inputs:` on a node whose `agent` has a `config.yaml` but no `graph.yaml`
@@ -848,7 +848,7 @@ fan_out_subjects:
   type: map
   over: "{{subjects}}"            # required; template must resolve to a JSON array
   as: subject                     # required; bound name inside each sub-branch
-  branch: research_subject        # required; ENTRY node of the per-item chain
+  branch: research_subject        # required; entry node of the per-item chain
   output_key: finding             # optional; state key the chain writes (default "output")
   collect_into: research_results  # required; state key to receive the array of results
   max_concurrency: 5              # optional; integer or "{{key}}" template
@@ -1447,7 +1447,7 @@ validator does not model. The most important of these is the implicit
 (the raw text, or the extracted object when `output_schema` is set). The
 binding is **transient**: the executor sets `output` to the completion,
 renders every `state_updates` template, then puts `output` back to whatever
-it was before the node ran — or to `null` if the key did not exist. An
+it was before the node ran, or to `null` if the key did not exist. An
 LLM/agent/rag node therefore **never persists its completion under
 `output`** on its own. If you want the completion to survive, name a key:
 
@@ -1456,8 +1456,8 @@ state_updates:
   finding: "{{output}}"
 ```
 
-Writing `output` explicitly also works — `state_updates: { output:
-"{{output}}" }` leaves `output` equal to the completion — but a named key
+Writing `output` explicitly also works (`state_updates: { output:
+"{{output}}" }` leaves `output` equal to the completion), but a named key
 is the recommended pattern, especially for map branches (pair it with the
 map's `output_key`, see [`map` nodes](#map)).
 
@@ -1469,8 +1469,8 @@ Two consequences of the restore step that bite in parallel super-steps:
   fork before the chain starts, so nothing is inherited), and the validator
   warns about it at load time. A chain node whose `state_updates` name
   *other* keys leaves `output: null` instead, so a map with the default
-  `output_key: output` collects `null` — one more reason to always declare
-  a named `output_key` and write it explicitly.
+  `output_key: output` collects `null`. This is yet another reason to 
+  always declare a named `output_key` and write it explicitly.
 - When `output` was **absent** from state before the super-step, every
   LLM/agent/rag branch that has `state_updates` leaves `output: null`
   behind (the restore falls back to `null`). Two or more such branches
@@ -1516,7 +1516,7 @@ merges them via the reducer pipeline.
 This means:
 
 - Branches can freely mutate state **during** the super-step without
-  stepping on siblings — but every key a branch wrote participates in the
+  stepping on siblings. But every key a branch wrote participates in the
   join, including the `output: null` residual an LLM/agent/rag node with
   `state_updates` leaves behind when `output` was previously absent, so
   any key written by 2+ branches needs a declared reducer (see
@@ -1921,7 +1921,7 @@ This is the developer-facing channel and includes:
 
 - Graph start / completion / failure
 - Per-node entry and routing decisions (`debug`)
-- A **performance summary** at completion — every node's visit count,
+- A **performance summary** at completion. Every node's visit count,
   total/avg/max wall-clock time, slowest first:
   ```
   [graph:my-agent] performance summary (slowest first):