Make the docs state things rather than argue them

The site read as a design journal: rationale paragraphs, hedges
("deliberately", "on purpose", "genuinely"), meta-commentary about the docs
themselves, and one em-dash every ten lines carrying an aside.

Roughly twenty rationale blocks are gone or reduced to what a reader needs
in order to use the thing. Em-dashes go from 507 to 135, and what is left is
structural rather than prose: list and definition separators, table cells,
and four inside code blocks that quote what the CLI actually prints.

Also: api.example.com becomes api.fluksio.com (the emails stay, since
bootstrap.py really defaults to admin@example.com and RFC 2606 reserves it);
the mqtt table gains the two settings it had drifted behind on and inject's
wording matches the engine; llms.txt lists the two connector pages that were
in the nav but not in it; and the two device/device_policy notes now agree.

Builds clean under `zensical build --strict`.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015YrQnKV3bnQd4K342y8tKj

docs/concepts/state.md

@@ -1,7 +1,7 @@
 # Keeping state in a flow
 
 Logic nodes are pure functions of their inputs. There is no `context`, no
-`global`, no handle to a store — a node is called with the values of the
+`global`, no handle to a store. A node is called with the values of the
 messages it declares and returns the values of the messages it provides.
 
 That is deliberate: a node with hidden state cannot be run twice in parallel,
@@ -10,7 +10,7 @@ automations need to remember something. This is how.
 
 ## State is a message the node both reads and writes
 
-A running total, a debounce timer, a last-seen reading — each is a value that
+A running total, a debounce timer, a last-seen reading: each is a value that
 survives between runs. Give it a message name, declare it as both an input and
 an output, and it is state:
 
@@ -36,7 +36,7 @@ first call is well-formed even if the value is missing.
 
 ## Feeding a value back between two nodes
 
-Sometimes the value comes from a different node — a controller reading back what
+Sometimes the value comes from a different node, such as a controller reading back what
 an estimator computed from its own last output. Written plainly that is a cycle,
 and the validator rejects it, because a graph where A waits for B and B waits
 for A can never start.
@@ -51,7 +51,7 @@ Say so, by marking the input non-triggering:
 A non-triggering input:
 
 - creates no dependency, so it cannot form a cycle;
-- never makes the node wait — if the message has no value yet, the port is
+- never makes the node wait. If the message has no value yet, the port is
   simply left out of the call, and the function's default applies;
 - is read fresh from state whenever the node does run, for whatever reason.
 
@@ -60,8 +60,8 @@ input, and marking it non-triggering would mean the node never runs at all.
 
 ## What still holds engine-side state
 
-Built-in nodes that are *about* time or change — rate limiting, filter-on-change,
-delay, cron — keep what they need in the engine's own state backend, under keys
+Built-in nodes that are *about* time or change (rate limiting, filter-on-change,
+delay, cron) keep what they need in the engine's own state backend, under keys
 that never appear as messages. That is the engine's business, not a flow's: the
 line is that node *code* you write never reaches for state, while node *types*
 the engine ships may.