fix(engine): a client that leaves must not kill the daemon, and a long round must say it started

Round 9.1, spec §3 D + ADR 0006 items 2 and 4. Two small changes, both proven
by measurement, both E2E-verified locally against a rebuilt brain.

D1 — SIGPIPE/EPIPE survival (vendor/el-runtime el_runtime.c).
Root cause, at the layer that owns it: the whole HTTP server lives in the C
runtime; .el has no socket primitive. http_send_all() called send() with flags
0 and nothing anywhere in the runtime set a SIGPIPE disposition, so the default
disposition — terminate the process — applied. When a handler finished after
its client had gone (Tim's VM: reply at 116.9 s, client cancelled at 25.0 s),
the second of the four sends that write one reply raised SIGPIPE and the daemon
died: `exited due to SIGPIPE ... ran for 361177ms`, launchd respawn 4 ms later,
every other in-flight session's work lost, user never told.

Fix: SIGPIPE -> SIG_IGN at runtime init and at each http_serve* entry, plus
per-connection SO_NOSIGPIPE / MSG_NOSIGNAL so the guard survives an embedder
resetting dispositions. http_send_all now retries EINTR and preserves errno;
http_send_response classifies it once — a departure is logged as routine
("client left before the reply was written ... reply discarded") and ANY other
errno is logged as a real "send failed: <strerror>". Spec §5.3: the routine
case must not mask a genuine write fault, and it does not.

Proof (scratch HOME + free port, 3 disconnects mid-reply):
  round-9 shipped brain 4402179554… — DIED, exit 141 (128+13 = SIGPIPE), round 1
  round-9 sources rebuilt with this exact recipe — DIED, exit 141, round 1
  this build — SURVIVED 3/3, /health 200 after, still serving the full graph,
  three honest "client left" lines in the log naming Broken pipe / Connection
  reset by peer.

D2 — the round-start marker (chat.el, agentic_loop).
The ledger only ever appended AFTER a round returned, so a healthy first leg
produced zero progress by construction; since server-side web_search moved
inside the outbound call that leg is 60-120 s of silence, which is how a 25 s
client watchdog came to kill a healthy mission. One entry,
{"i":N,"t":"","tool":"__working__"}, written to the existing
run_progress_<session_id> ledger BEFORE each round's outbound call — the wire
shape ChatView.kt:1148 has handled as a life signal since 2026-07-13 and never
received. No new key, no new route, no new lifecycle: a strict subset of WS3
item 3. WS3's run registry is untouched and stays Will's.

Proof (live Anthropic key, real research mission, scratch HOME + free port):
  round-9 baseline — ledger EMPTY for the whole 59.7 s leg
  this build       — {"i":0,"t":"","tool":"__working__"} visible at 18.6 s of a
                     70.0 s leg; both builds returned correct ~4.9 KB answers

Regression: prompt-matrix gate 32/32 on this build (round-9 baseline also 32/32
under the same recipe, so the score is not a build artifact). Soul contract
gate PASS — 27/27 routes, immutability clean. neuron#111 miscompile guard: 0
sites in the generated amalgam this binary was compiled from.

NOT included, deliberately: the regenerated dist/soul.c. CI compiles that file,
so production stays exposed until it is regenerated — the same open ask as
neuron#111 / ui#209. The regen recipe is now known and recorded; landing it is
Will's call, per BUILD-HYGIENE.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

chat.el

@@ -2837,6 +2837,30 @@ fn agentic_loop(session_id: String, model: String, safe_sys: String, tools_json:
             + ",\"messages\":" + messages
             + "}"
 
+        // ── ROUND-START MARKER (2026-08-06, round 9.1 D2 / ADR 0006 item 2) ──────────
+        // The ledger below only ever appended AFTER a round returned, so a healthy
+        // first leg produced ZERO progress by construction. Since server-side
+        // web_search moved inside the outbound call (2026-08-04) that leg measures
+        // 84-117 s, and the client had no way to tell "working" from "dead" — which is
+        // how a 25 s client-side watchdog came to kill a healthy mission.
+        //
+        // Only this loop knows a round has started, so only this loop can say so. One
+        // entry, written BEFORE the call goes out, using the ledger and the wire shape
+        // that already exist: the app has handled tool == "__working__" as an
+        // Activity-only life signal since 2026-07-13 (ChatView.kt:1148) and never
+        // received one. Narration is deliberately empty - the marker means "a round
+        // started", nothing more, and the client renders it as a heartbeat, not prose.
+        //
+        // This is a strict subset of WS3 item 3 (push/poll progress). It builds none of
+        // WS3's run registry: no new state key, no new route, no new lifecycle.
+        if !str_eq(session_id, "") {
+            let start_key: String = "run_progress_" + session_id
+            let start_prev: String = state_get(start_key)
+            let start_entry: String = "{\"i\":" + int_to_str(iteration) + ",\"t\":\"\",\"tool\":\"__working__\"}"
+            let start_next: String = if str_eq(start_prev, "") { start_entry } else { start_prev + "," + start_entry }
+            state_set(start_key, start_next)
+        }
+
         let raw_resp: String = http_post_with_headers(api_url, req_body, h)
 
         let is_error: Bool = str_starts_with(raw_resp, "{\"error\"")