Story: Extract a sync sibling of run_host_async for ores.cli/ores.shell

Extract a sync sibling of run_host_async that both ores.cli and ores.shell's host.cpp can use, closing the ~70% structural duplication between them (parse args -> check config -> init lifecycle_manager -> log args/config -> try { construct; run; } catch { diagnostic_information dance }) without forcing either tool onto the async daemon helper — per the investigation in Review whether ores.cli/ores.shell's host.cpp divergence is load-bearing or historical, sync execution is load-bearing for both. The helper must be parameterised by an application-construction callable (neither tool's constructor is uniform with the other) plus an optional early-exit hook (for cli's DB-free ore_roundtrip branch).

• New sync sibling helper (parameterised by an application-construction callable and an optional early-exit hook) extracted, covering the shared parse/init-logging/log/try-construct-run/catch-diagnostic shape
• ores.cli's host::execute rebuilt on the new helper, preserving its output_stream_ reference-member constructor and its DB-free ore_roundtrip branch (via the early-exit hook)
• ores.shell's host::execute rebuilt on the new helper, preserving its REPL semantics
• No behavioural change to either tool; existing tests pass unchanged

• Early-exit must run before the shared try/catch, not inside a runner lambda wrapped by it — folding cli's roundtrip branch inside the generic try/catch would double-log its errors (once via its own catch, once via the generic "Error:"/"Failed to execute command." pair), changing observable behaviour.
• No attempt to unify application construction across the two tools; the shared helper only owns the parse/init-logging/log/try-catch envelope, with construction+run delegated entirely to a per-tool callable.

• Moving either tool onto the async run_host_async helper (rejected by the investigation: sync execution is load-bearing for both)
• Any change to the daemon fleet's async envelope