Conductor front doors: web conductor pane + Telegram routing (P5)

[saucam]

The largest gap between "the conductor is implemented" and "the conductor is usable". Specced in conductor-frontends-design.md; status recorded honestly in conductor-design.md §7 as of #275.

Current state, measured

• Web: 5 references to conductor across web/src, all incidental (lib/auth.ts, PipelineRunner.tsx, state/pipelines.ts). No conductor pane.
• Telegram: zero references to conductor in src/frontends/telegram/. No routing.
• The only front door is codeoid attach conductor in a terminal (client.ts:485).

Meanwhile P0–P4 are shipped: six fleet read verbs, four send verbs, durable dispatch queue with lease reclaim and failure auto-block, durable owner-delegated identity, panels, and collaboration. The backend is well ahead of the reachability.

Why this is first in the reframe ordering

1. Nothing else in the assistant vision is reachable without it.
2. It is what generates the data. There are currently 0 conductor sessions, 0 fleet.* audit rows, and 0 dispatch tasks on the dev box — so every downstream decision (retrieval tuning, whether a local open-weight backend can drive it, prompt composition) is being made without usage. Dogfooding is gated on a front door.
3. The protocol needs no new wire types — confirmed by the mobile plan §8 and restated in the build plan. The conductor is just a session; clients light it up by attaching to it, and fleet actions render as ordinary tool calls in the transcript. So this is client work, not protocol work.

Scope

• Web (SolidJS): a conductor pane that attaches to the role: "conductor" session, plus the existing session list as a separate switchable view
• Telegram: route DMs to the conductor session; /sessions to list and switch. Note local mode refuses Telegram by design (local-mode.md) — this path requires ZeroID auth
• Approval prompts for send-class dispatch render natively in both (they ride the existing approvalId correlation flow, so this is rendering, not new mechanism)
• Both stay thin Frontend plugins over daemon-owned state — no new state owner

Deliberately out of scope

The protocol-level fleet.find message for an LLM-free instant search box. Downgraded to optional in the build plan; v1 clients get search by talking to the conductor.

Related

• feat: native mobile app (iOS/Android) for Codeoid #43 native mobile app — its P5 depends on this shape but not on this work
• feat: Slack and Discord connectors — additional Frontend implementations #59 Slack/Discord connectors — same Frontend seam, later