Factor runSiteWith into siteInput + runSiteWithInput

[srid]

runSiteWith now composes out of two steps — siteInput (build the Dynamic) and runSiteWithInput (consume it). The same class of problems that motivated currentValue (#177) — teeing the Dynamic for an out-of-band consumer — needs a seam between those two steps. Before this PR, runSiteWith sealed them together; the only escape was plumbing a callback through the user's SiteArg, which either conflated config with transport wiring or (worse) bypassed the user's siteInput entirely.

The user's siteInput still runs. Callers that need the tee just invoke siteInput themselves, compose (currentValue, <*>, whatever), and pass the result to runSiteWithInput. Callers that don't need it keep using runSiteWith exactly as before — its body is now a two-liner:

runSiteWith cfg arg = flip runLoggerLoggingT (getLogger …) $ do
  dyn <- siteInput @r (CLI.action cli) arg
  runSiteWithInput cfg dyn

runSiteWithInput is polymorphic in m (MonadUnliftIO m, MonadLoggerIO m, MonadFail m), which also lets the live-server race stay in one logger context — UnliftIO.Async.race_ replaces Control.Concurrent.Async.race_, and both branches run in m directly. Net: the existing liftIO $ race_ / runLoggingT logger scaffolding collapses, and async drops out of the direct deps (it's still pulled in transitively via unliftio).

Fully additive. runSite, runSite_, runSiteWith are unchanged in signature and behaviour. runSiteWithInput is a new export.

Motivated by srid/emanote#649's MCP server: with this PR, emanote drops its tapModel helper, the _emanoteConfigOnLiveModel callback field, and the publish-through-config plumbing entirely — MCP and Ema compose via race_ at the call site.

Try it locally

nix build github:srid/ema/feat/run-site-with-input

[srid]

Hickey/Lowy Analysis

#	Lens	Finding	Disposition
1	Hickey	MonadFail m on runSiteWithInput unforced — only used by CLI.crash's fail	Fixed (569a17f)
2	Hickey	Doc snippet in dynamic.md uses superfluous withRunInIO	Fixed (5a0399c)
3	Hickey	cwd log side-effect inside runSiteWithInput body	Deferred — would need a withEmaStartup bracket; blast radius is test-log noise, not correctness
4	Hickey	runSiteWith handles logger; runSiteWithInput assumes caller's context	No-op — the asymmetry is the point of the factoring
5	Hickey	async → unliftio dep swap	No-op — minimal change needed for polymorphic m
6	Lowy	siteInput ↔ runSiteWithInput boundary correctness	No-op — encapsulates composition volatility exactly once
7	Lowy	Constraints undocumented	Fixed (folded into 569a17f — inline rationale added)
8	Lowy	MonadFail weak contract across monads	Fixed (subsumed by #1 — now uses throwIO on userError)
9	Lowy	runSiteWith two-liner shape	No-op — correct orchestrator role
10	Lowy	Forward-compat with future subscribe/fanout	No-op — fits the same three-line pattern, no redesign needed

Hickey rationale

The factoring decomplects the right things: runSiteWith now owns logger setup + orchestration, runSiteWithInput owns dispatch (Generate vs Run) + race. What was conflated before (Dynamic acquisition + consumption) is now separable. The one structural smell I found was MonadFail m carried purely because CLI.crash used fail — a weak contract for a "never returns" path. Dropping it via throwIO shrinks both CLI.crash's and generateSiteFromModel's constraint sets, and removes MonadFail from the library entirely.

The cwd log inside runSiteWithInput is a minor braiding of startup observability into Dynamic consumption, but extracting it needs a bracket-style primitive and the blast radius is small. Deferring.

Lowy rationale

The composition-volatility axis (what callers do between Dynamic build and consume) is now fully owned by the caller, which is where it belongs — runSiteWithInput is oblivious to tee/fanout/subscribe patterns. The polymorphism in m correctly exposes driver constraints that were previously hidden inside runSiteWith's IO monomorphism — this is necessary for downstream composition, not a leak. A future subscribe :: Dynamic m a -> m (TChan a, Dynamic m a) primitive drops into the same siteInput → tee → runSiteWithInput three-liner without changing this API — forward-compatible by construction.

The MonadFail finding converged with Hickey #1 and was fixed there.