feat: finalize HTTP direct dispatch refactor and pending milestone updates

Switch API execution to direct daemon request handling, add regression
coverage for non-socket HTTP dispatch, and include the remaining pending
local updates across CLI/daemon/docs from the current worktree.

PROJECT_MAP.md

@@ -2,7 +2,7 @@
 # tvctl — Living Project Map
 # This file is the single source of truth for any agent working on this project.
 # Read this first. Update this when you make structural changes.
-# Last updated: 2026-04-14
+# Last updated: 2026-04-18
 
 ---
 
@@ -19,7 +19,7 @@ script and control smart TVs through a stable, brand-agnostic API.
 
 ## Project Status
 
-**Phase:** Milestone 5 in progress. Daemon core and CLI are complete for v1 Roku control, and the `/v1` HTTP API server is now wired to the same daemon request surface. Remaining work is automated API validation and any follow-up transport cleanup.
+**Phase:** Milestone 6 in progress. Daemon core, CLI, and `/v1` HTTP API are complete for v1 Roku control. Remaining work is release prep (service verification, cross-compile, CI, first release).
 **Platform v1:** Roku only (via ECP HTTP API)
 **Language:** Rust
 **Crate type:** Binary (single binary distribution target)
@@ -45,6 +45,7 @@ tvctl/
 ├── src/
 │   ├── lib.rs              ← Library surface for shared modules and integration tests
 │   ├── main.rs             ← Binary entry point and runtime bootstrap
+│   ├── logging.rs          ← Tracing initialization and runtime log-filter reload
 │   ├── cli/                ← CLI layer (clap-based scaffold)
 │   │   └── mod.rs
 │   ├── daemon/             ← tvctld daemon core scaffolding
@@ -108,6 +109,10 @@ CLI (tvctl)
                     └── /v1/... (tool builders)
 ```
 
+The CLI reaches the daemon over the Unix socket. The HTTP API runs in the same
+process and dispatches directly into the daemon request executor instead of
+looping back through the socket layer.
+
 ---
 
 ## Adapter Trait