plan: don't calcify P0.2 — artdag may grow to contain business logic (phase AX)

Per the user: the execute-fold-vs-artdag split from P0.2 is a capability SNAPSHOT, not a permanent
boundary. artdag MAY grow +{effect,branch,each} node-kinds; business logic then migrates onto it to
inherit the DAG-engine superpowers — content-addressed memoization (recompute only on input-CID
change), optimize (fuse/dedup/dce), schedule, and above all FEDERATION (a flow result reused across
peers by content-id — the federation vision, for free). The capability model makes the migration
seamless (same DAGs + seam; the runner just advertises more). Named the real design work: dynamic
control in a static DAG (branch prunes a path); effect nodes non-cacheable vs pure nodes memoized.
Demand-driven (phase AX); execute-fold stays the lean default for cheap synchronous flows. Annotated
the P0.2 finding + flows.sx header so the finding doesn't harden into dogma.

Doc/comment-only.

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

lib/host/flows.sx

@@ -6,6 +6,10 @@
 ;; artdag runner (dataflow, memoized/parallel). The DIFFERENCE is which capabilities their nodes
 ;; need. A node declares its capability; a runner ADVERTISES what it supports; the binder checks
 ;; required ⊆ advertised (fail fast); so the sync/durable/distributed choice is DERIVED from the DAG.
+;; NOTE (plan phase AX): this execute-fold-vs-artdag split is a capability SNAPSHOT, not a boundary
+;; — artdag MAY grow +{effect,branch,each} node-kinds and business logic then migrates onto it (to
+;; inherit content-addressed memoization / optimize / FEDERATION). The capability model makes that
+;; migration seamless; the execute-fold stays the lean default for cheap synchronous flows.
 
 ;; ── capability typing: a node kind → the capability it needs ──────────
 (define host/flow--node-cap