refactor(driver): require daemon-backed dispatch

[f-trycua]

Summary

• make cua-driver call, configuration commands, diagnostics, and MCP dispatch go through the daemon
• remove daemonless/in-process MCP and CLI fallback paths while keeping daemon-owned tool execution intact
• update embedded-host startup, test infrastructure, policy tests, skills, and docs for the daemon-only process model

Why

Permission policies, desktop identity, session state, and telemetry need one authoritative execution boundary. A daemonless fallback could bypass that boundary or execute against a different desktop/session than the long-lived driver.

Behavior changes

• cua-driver call <tool> now fails when no daemon is available instead of invoking a local registry
• MCP is always a stdio-to-daemon proxy; the old no-relaunch switch and in-process server path are removed
• macOS standalone mode may launch the app-owned daemon; Windows/Linux require an already-running daemon
• embedded hosts must start serve --embedded --socket ... before starting mcp --embedded --socket ...

Tests

• cargo fmt --all -- --check
• cargo check -p cua-driver -p cua-driver-testkit
• cargo test -p cua-driver-core --lib (291 passed)
• cargo test -p cua-driver --bin cua-driver (103 passed)
• cargo test -p cua-driver-testkit --lib (46 passed)
• cargo test -p cua-driver --test daemon_required_test --test protocol_handshake_test --test protocol_tools_call_test --test protocol_schema_test --test transport_config_persistence_test (24 passed, 2 intentionally ignored)
• xcrun swiftc -typecheck ExampleAgentHarness.swift -framework ApplicationServices
• daemonless-path audit confirms the binary's only remaining registry.invoke is in serve.rs