chore(maestro): retarget installer, e2e harness, and docs at unified maestro binary (NAP-245)

- Installer: one `cargo install maestro` instead of two; ExecStart becomes
  `~/.cargo/bin/maestro daemon`; user unit renamed `maestrod.service` →
  `maestro.service`; configure step is `maestro daemon configure`.
- E2E harness: both `Daemon` and `Registry` subprocess wrappers shell out to
  the unified `maestro` binary with the appropriate subcommand.
- State dir: `~/.local/state/maestrod` → `~/.local/state/maestro`.
- Docs: CLAUDE.md repo layout, design spec repo layout + "Daemon (`maestro daemon`)"
  heading, INSTALL.md (full rewrite of CLI references + new thin-builds section).

docs/superpowers/specs/2026-05-24-maestro-design.md

@@ -61,7 +61,7 @@ UI polish, layout/tiling, edge-case terminals — all out of scope.
 Three components, all reachable over an operator-managed network (LAN, VPN, mesh — maestro is network-agnostic; the operator configures bind addresses and ensures clients can route to them):
 
 - **Registry** — one always-on instance. Knows who's online and what sessions exist. Serves the web client bundle. Never touches PTY bytes.
-- **Daemon (`maestrod`)** — one per host. Wraps local tmux. Streams sessions directly to clients over WebSocket.
+- **Daemon (`maestro daemon`)** — one per host. Wraps local tmux. Streams sessions directly to clients over WebSocket.
 - **Web client** — one TS bundle. Connects to the registry for the catalog, then directly to whichever daemon owns the session being attached.
 
 The registry is a phone book, not a relay. This keeps it tiny and pushes byte traffic to a direct daemon ↔ client link. Confidentiality of that link is the operator's responsibility (Wireguard, a private LAN, mTLS in a future iteration — maestro itself does not encrypt at the transport layer beyond what the operator's network provides).
@@ -85,7 +85,7 @@ Non-responsibilities:
 
 Runs as a single Rust binary on a designated VM. Listens on a configured `bind_addr` (default `127.0.0.1:8080`; operator sets the actual reachable address — e.g. a Wireguard interface IP — in `[registry].bind_addr` of the unified config at `~/.config/maestro/config.toml`).
 
-### Daemon (`maestrod`)
+### Daemon (`maestro daemon`)
 
 Responsibilities:
 
@@ -253,16 +253,21 @@ Single-user trust model. The operator's network (Wireguard / private LAN / etc.)
 
 ## Repo layout
 
-Cargo workspace:
+Cargo workspace. NAP-245 collapsed the three binaries (`maestro`, `maestrod`, `maestro-registry`) into a single `maestro` binary with feature-gated subcommands. Library crates kept their existing shape; per-binary `main.rs` files are gone.
 
 ```
 maestro/
 ├── Cargo.toml                    # workspace
 ├── crates/
-│   ├── maestro-protocol/         # message types, shared between binaries
-│   ├── maestro-registry/         # registry binary
-│   ├── maestro-daemon/           # daemon binary
-│   └── maestro-cli/              # `maestro` CLI for scripting (spawn/list/kill from shell)
+│   ├── maestro/                  # umbrella binary: `maestro <list|spawn|attach|kill|set-registry|policy|daemon|registry>` (features: cli/daemon/registry)
+│   ├── maestro-protocol/         # message types, shared between subsystems
+│   ├── maestro-config/           # unified on-disk config schema
+│   ├── maestro-cli/              # CLI subcommand types + dispatch (library)
+│   ├── maestro-daemon/           # daemon subsystem (library + `maestro daemon` dispatch)
+│   ├── maestro-registry/         # registry subsystem (library + `maestro registry` dispatch)
+│   ├── maestro-web/              # standalone `maestro-web` browser-UI binary
+│   ├── maestro-installer/        # `maestro-install` wizard
+│   └── maestro-e2e/              # cross-process integration tests
 ├── web/
 │   ├── src/
 │   ├── package.json
@@ -273,7 +278,7 @@ maestro/
 └── CLAUDE.md
 ```
 
-`maestro-cli` is a low-priority bonus — handy for scripted spawning and for testing the registry HTTP API. Drops out of scope if it slows the plan.
+Thin builds for single-role hosts: `cargo install --no-default-features --features {cli|daemon|registry} maestro` produces a binary with only that subsystem's dependencies compiled in.
 
 ## Out of scope (prototype)