Audit competing coding-agent control planes and define product priorities

## Parent and milestone

- Parent issue: #23
- Milestone: not scheduled; this audit must complete before the future runtime
and multi-host roadmap is funded or scheduled.

## Problem

Remote coding-agent control, mobile supervision, multi-agent clients, secure
relays, and self-hosted execution platforms have matured rapidly. Building the
existing roadmap without a source-linked competitor and standards audit risks
duplicating free products, inventing agent adapters already covered by ACP, and
investing in features that do not create a defensible user outcome.

## Outcome

Publish a dated competitive landscape, compare current and planned Durex
capabilities with direct and adjacent products, identify the remaining product
wedge, and convert the result into explicit P0/P1/P2/deferred roadmap
priorities and a measurable validation gate.

## Scope

- Profile official Codex remote access, Happy, Happier, CouchCode, Omnara,
GitHub Copilot Mobile, Coder Agents, Ona, Daytona, and OpenHands.
- Distinguish direct remote-control products from enterprise control planes,
secure execution infrastructure, and complete agent platforms.
- Compare transport, mobile, voice, self-hosting, encryption, agent coverage,
multi-host, workspace isolation, queueing, governance, extensibility, and
commercial model using primary sources.
- Compare those capabilities with Durex behavior available on the audited
branch and separately label planned behavior.
- Audit Agent Client Protocol as the default interoperability path before
bespoke runtime adapters.
- Define a focused product position, implementation priorities, explicit
non-goals, and commercial validation criteria.
- Record licensing and naming as commercialization prerequisites.

## Non-goals

- Implementing competitor features or runtime adapters.
- Treating missing public documentation as proof that a feature does not exist.
- Selecting a product direction from star counts or vendor marketing alone.
- Building a mobile application before the transport-neutral API is validated.

## Acceptance criteria

- [ ] Every product profile links current first-party documentation or its
canonical open-source repository and records the review date.
- [ ] The comparison distinguishes available, partial, planned, absent, and not
documented capabilities.
- [ ] Durex gaps are converted into P0/P1/P2/deferred priorities with rationale
and owning issues where known.
- [ ] ACP is evaluated before Codex, OpenCode, and Pi adapter implementation.
- [ ] A measurable product validation gate prevents unvalidated enterprise
expansion.
- [ ] README, architecture, system overview, and roadmap navigation are updated.
- [ ] Documentation and regression checks pass.

## Validation

- Re-check all source links and review dates.
- Compare the matrix with current README behavior and open GitHub issues.
- Run documentation checks and the existing regression suite.

## Dependencies

- #15 remains the current implementation gate.
- #25 owns detailed runtime capability probes.
- #36 owns reproducible plugin and token-optimization benchmarks.

Start with the current README, architecture, system overview, roadmap navigation, and Durex behavior on the audited branch. Profile each named product and ACP from primary sources, recording review dates and capability status, then map Durex gaps to P0/P1/P2/deferred priorities and validation criteria. Re-check source links and run documentation checks plus the existing regression suite when the updated documentation is complete.

Written by the indexing model from the issue text.