feat: Phase 1 ACP adoption — Codex adapter via ACP transport (#125)

[c-h-]

Summary

Implements Phase 1 of ADR-001 (merged in #126): adopt ACP as the primary agent interface for agentctl.

What's included

• Generic ACP adapter (src/adapters/acp/) — reusable ACP transport layer
• ACP client (src/adapters/acp/acp-client.ts) — session lifecycle management (create, send, poll, terminate)
• Codex-ACP adapter (src/adapters/codex-acp.ts) — launches Codex via ACP instead of PTY
• CLI registration — codex-acp available as adapter option in agentctl launch

Stats

• 1,049 lines added across 10 files
• 24 new tests (513 total, all passing)
• Zero lint/build errors
• Full backward compatibility — existing PTY adapters untouched

Testing

npm test  # 513 passed (32 test files)
npm run lint  # 0 issues
npm run typecheck  # clean

Phase 1 of #125.

[c-h-]

Nice direction overall, and CI is green, but I don't think this is merge-ready yet.

Blocker 1: codex-acp isn't actually shipped here.
The PR registers codex-acp in the CLI and src/adapters/codex-acp.ts says it falls back to the existing PTY adapter, but package.json only adds @agentclientprotocol/sdk; it does not add the @zed-industries/codex-acp bridge binary, and there's no fallback logic in the code. On a fresh install, agentctl launch codex-acp will just fail if codex-acp isn't already on PATH. Either vendor/install the bridge, document it as an explicit prerequisite, or keep this adapter experimental/unregistered for now.

Blocker 2: the ACP adapter isn't discover-first yet.
discover(), status(), resume(), and stop() all depend on the in-memory clients map populated by launch(). That means a fresh CLI process — or a daemon restart — can't rediscover or control existing ACP sessions. That's a pretty fundamental mismatch with agentctl's current contract and with the ADR claims about session persistence / crash recovery. I think Phase 1 needs either a real ACP rediscovery/reattach story, or this should stay behind an experimental flag until that exists.

Docs audit: README is stale once this lands. The CLI reference and adapter docs still list only claude-code, codex, opencode, pi, pi-rust, openclaw, and there's no install/usage section for codex-acp or its prerequisites. That should be updated before merge if the adapter stays user-visible.

Happy path / architecture direction looks good; I'd just fix the packaging + discoverability story before merging.