Consolidate session-launch plumbing: coven run vs POST /sessions

[BunsDev]

Duplication (from the workstream-3 CLI-vs-daemon survey)

The CLI coven run path and the daemon POST /sessions handler implement the same launch steps twice:

Step	CLI	API
project root / cwd resolution	main.rs ~2771-2778	api.rs ~1686-1690
harness existence/availability validation	main.rs ~2769 + selected_available_harness ~3688-3710	api.rs ~1691-1705 (validates against configured_harness_specs)
familiar resolution	main.rs ~2792-2797	api.rs ~1503-1522
session record creation + insert	main.rs ~2922-2944	api.rs ~1523-1542
event/delegation emission	main.rs ~2961-3365	api.rs ~1557-1570 (coven_calls::emit_running)

Drift already present: the CLI adds prompt expansion, stream-json/detach/resume logic, and harness-specific option warnings; the API is stricter about payload shape with structured HTTP errors; the two sides even validate harness availability through different helpers.

Proposal

Extract a shared launch-preparation core (resolve project root, validate harness, resolve familiar, build the SessionRecord) consumed by both main.rs and api.rs::launch_session, leaving CLI-only UX (prompting, TTY detection, stream-json, detach) and API-only concerns (payload parsing, HTTP error mapping) at the edges.

Risk: highest of the surveyed candidates. Touches the daemon protocol contract (docs/API-CONTRACT.md POST /sessions section), session record shape, and CLI foreground UX. Needs a careful test-pinning pass (api.rs launch_request_* tests + scripts/test-cli-prepublish.mjs) before refactoring. Deliberately deferred from #396 (paths consolidation, merged in #400).