Converge the duplicate Archon and Syndesis renderer transports

[forkwright]

Finding

Harmonia currently maintains two independent QUIC renderer stacks for the same product capability: crates/syndesis and crates/archon/src/render. The running archon binary uses its private renderer implementation, while archon still declares a dependency on syndesis without importing it in production code. Documentation nevertheless presents syndesis as the active QUIC renderer subsystem.

The two stacks are no longer alternate adapters over one protocol. They define different session negotiation, frame shapes, identifiers, status fields, audio payloads, authentication surfaces, and synchronization capabilities. Security and admission fixes have consequently landed independently in both implementations.

Verified against main 65644113e47814c87eaba14a6f322820974b8780.

Evidence

• crates/archon/Cargo.toml:25-41 declares both the normal subsystem dependencies and syndesis.workspace = true; exact source search for syndesis:: at this revision finds no production use from Archon — only comments in archon/src/render/server.rs, a Horismos comment, and Syndesis's own integration test.
• crates/archon/src/render/server.rs:152-190 runs Archon's own QUIC renderer server and explicitly says its live admission gate "mirrors syndesis::ServerConfig::max_sessions, the sibling QUIC admission surface in this workspace."
• crates/archon/src/render/protocol.rs:7-83 defines Archon's protocol: four message kinds, PROTOCOL_VERSION: u32 = 1, string session IDs, raw Vec<f64> audio samples, and its own session/status DTOs.
• crates/syndesis/src/protocol/frame.rs:8-79 defines a different renderer protocol: sequence numbers, microsecond/playout timestamps, codec negotiation, Bytes payloads, clock-sync frames, u64 session IDs, renderer IDs, and command frames.
• README and docs/architecture/binary-modes.md describe renderer transport as syndesis, while the live serve path calls archon::render::server::start_renderer_server.
• Commit cd985253ce5f3e336ba21478bdac618713e9ee87 already recorded the topology explicitly when it deleted SyndesisConfig: "syndesis is never constructed from archon" and paroche.renderer_max_connections serves the live max-session role.
• The maintenance fork is observable in history: e71cd8d6384eb97a77b4903658a2e52395e644ba separately hardened the Syndesis renderer transport, while cf1fb43b4c26c358152152e1b58fcf2579a0b9e2 separately hardened Archon's renderer TLS/QUIC transport.

This is not a legitimate client/server or trust-boundary mirror: both implementations claim ownership of the same Harmonia renderer transport and Archon can function without consuming the Syndesis implementation.

Why this matters

Renderer authentication, TLS pinning, admission limits, message bounds, clock behavior, and wire compatibility are security/correctness properties. With two owners, a fix to one transport does not protect the other, and a renderer compatible with one protocol is not necessarily compatible with the other even though repository documentation presents a single capability.

It also makes syndesis expensive to reason about: the crate appears to be a first-class workspace subsystem and receives maintenance, yet the actual binary reimplements the capability beside it. That is exactly the "machinery exists that nothing uses" plus "one concept implemented twice" combination this audit is intended to eliminate.

Desired correction

Choose one renderer transport as the canonical implementation based on the current product requirements, then make the running binary consume it directly. Preserve genuinely unique capabilities from the losing side only where they are still required; do not keep a second complete protocol merely as reference.

If Syndesis remains canonical, Archon's server/client/protocol/TLS/session code should become thin composition/adapters over it. If Archon's implementation is now the intended architecture, move any required clock/zone/pairing primitives into that owner and delete the unused Syndesis dependency/crate surface. In either case, make README/architecture docs derive from the actual owner and add an interoperability/contract witness during convergence.

Done when:

• exactly one production renderer wire protocol, TLS/auth policy, session-admission policy, and session lifecycle exists;
• archon has no unused renderer dependency or parallel private implementation;
• the selected renderer client and server complete one integration round trip through the same protocol types;
• renderer security fixes have one transitive owner rather than two maintenance targets; and
• README and binary-mode architecture name the implementation the running binary actually uses.