host: per-request IO kernel fix + fully-dynamic blog (no cache), 159/159

KERNEL (sx_server.ml): route http-listen handlers through cek_run_with_io
instead of bare Sx_runtime.sx_call, so handlers resolve per-request IO
(durable persist reads/writes) via the same IO-driving runner the REPL uses.
Verified: per-request read+write, 10 concurrent writes (15 on disk, no
corruption), handler errors don't crash the server, http contract 6/6.

BLOG: fully dynamic — host/blog-post reads the post from the durable store
(content/head) AND renders (content/html) per request, no in-memory view, no
cached output. Possible because of the IO fix. Honest ~2s due to interpreted
Smalltalk render.

Render speed is NOT solved here: the JIT (precompiler) isn't installed in the
serving mode and currently miscompiles the Smalltalk evaluator's nested ASTs
(enabling it breaks ~60% of tests). Fixing the JIT is a separate, high-payoff
effort. Documented in the plan.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

plans/host-on-sx.md

@@ -41,13 +41,28 @@ router, feed, relations, blog, server, ledger). Blog posts now persist in the
 durable SX store (`persist/durable-backend`, on-disk under `$SX_PERSIST_DIR`),
 materialised into an in-memory view at boot and served from there.
 
-> **Per-request IO gap (kernel):** `http-listen` handlers run via
-> `Sx_runtime.sx_call`, which does NOT drive `perform`/IO to completion the way
-> the main eval loop does (`Sx_types._cek_io_resolver` is global but the handler
-> path returns the suspension). Proven: a handler doing a durable `persist/read`
-> returns an empty/broken response. Workaround for blog reads = materialise at
-> boot. REAL FIX (next): make the http-listen handler invocation resolve IO like
-> the main loop — then handlers can read/write the store per request. Phases 1 & 2 DONE; Phase 3 cut-over
+> **Per-request IO (kernel) — FIXED.** `http-listen` handlers used to run via
+> `Sx_runtime.sx_call` (bare CEK, no IO resolution), so a handler doing a durable
+> `persist/read` returned an unresolved suspension. Fixed in `sx_server.ml`: the
+> handler now runs through `cek_run_with_io` (`Sx_ref.continue_with_call` →
+> `cek_run_with_io`), the same IO-driving runner the REPL uses — it resolves
+> persist ops via `Sx_persist_store.handle_op` between CEK steps. Verified:
+> handlers do per-request durable reads + writes (incl. 10 concurrent, 15 events
+> on disk, no corruption); handler errors don't crash the server. NOTE: this is
+> the per-request *IO* fix; it does NOT speed up the interpreted Smalltalk render
+> (`/welcome/` still ~2s) — that's a separate concern, addressed by caching the
+> rendered HTML at boot. (Pre-existing: an erroring handler closes the connection
+> with no response instead of a 500 — worth improving later.)
+>
+> **Render speed (separate from IO) — NOT precompiled.** `/welcome/` is ~2s because
+> the interpreted Smalltalk-on-SX render runs on the tree-walking CEK: the JIT hook
+> (`register_jit_hook`) is installed only in `--http` page mode, not the epoch/
+> http-listen serving mode (`make_server_env`), so zero `[jit]` activity. Enabling
+> it in that mode breaks correctness (router 3/6, feed 4/11, … — the known JIT-
+> bytecode bug on complex nested ASTs, which the Smalltalk evaluator is). So the
+> render is slow until the JIT compiler is fixed (big win, broad payoff — its own
+> loop) or the Smalltalk interpreter is optimised. Blog is FULLY DYNAMIC (reads
+> store + renders per request, no cache) — slowness is honest, not hidden. Phases 1 & 2 DONE; Phase 3 cut-over
 landed (50% off Quart). **The host now serves live HTTP** — `lib/host/server.sx`
 bridges the native `http-listen` server to the Dream app and `lib/host/serve.sh`
 boots it (verified: GET /health, /feed, /feed?actor=, relations get-children/