host: blog persisted in durable SX store + materialised view, 158/158

Blog posts now live in the durable SX store (persist/durable-backend, on-disk
under $SX_PERSIST_DIR — already built: sx_persist_store.ml + lib/persist/
durable.sx). Publishing appends insert ops to the slug's content stream; posts
survive restarts (verified: seq/log stable across container restart, re-seed
idempotent).

Read path: http-listen handlers can't drive per-request perform/IO (sx_call
doesn't resolve the CEK IO suspension the way the main loop does), so posts are
materialised from the store into an in-memory view at boot (host/blog-load-all!
+ host/blog-seed!) and request handlers read the view — perform-free. Store is
source of truth; view is a boot-rebuilt cache.

Deploy: docker-compose.dev-sx-host.yml mounts /root/sx-host-persist (chowned to
appuser 10001) at /data/persist; SX_PERSIST_DIR set. blog.rose-ash.com/welcome/
live. Per-request-IO kernel fix tracked in the plan as the next task.

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

plans/host-on-sx.md

@@ -36,8 +36,18 @@ host — no `ocaml-on-sx` dependency.
 
 ## Status (rolling)
 
-`bash lib/host/conformance.sh` → **156/156** (9 suites: handler, middleware, sxtp,
-router, feed, relations, blog, server, ledger). Phases 1 & 2 DONE; Phase 3 cut-over
+`bash lib/host/conformance.sh` → **158/158** (9 suites: handler, middleware, sxtp,
+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
 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/